Mail Archives: cygwin/2006/10/04/21:31:07
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Christopher Faylor on 10/4/2006 5:24 PM:
>>
>> Seriously, I'd have a hard time believing that supporting <CR><LF>
>> endings would noticably impact performance if it were done as part of
>> upstream BASH.
>
> You haven't been paying attention, it seems.
>
> We've already been over this ground. The performance impact for turning
> on bash's automatic CRLF handling is profound. That's why we're here.
Actually, the performance impact of reading a \r\n file on a binary mount
using my igncr option is much less than the performance impact of the
pristine sources, seeing as how my patch allows reading a buffer at a time
rather than the original reading a character at a time, and I/O time is
more of a bottleneck than character filtering once the data is read in.
On the other hand, igncr has a slight performance penalty on text mounts,
due to the additional branch instruction for every single character read,
only to find that text mounts don't produce \r in the first place. And on
binary mounts, files with plain \n are slightly penalized by the mere
existence of igncr, again because I added a branch instruction in the code
path of reading every character.
But as long as igncr is present, then I am seriously thinking of turning
it on by default on cygwin. And yes, if I do this, then I can remove the
special casing of DOS path names (although the speed penalty of calling
cygwin_conv_to_posix_path once per file is generally less than the speed
penalty of checking whether igncr is set once per character). And we
would be back to the behavior of bash-3.1-6 of gracefully handling \r\n by
default, except that on binary mounts the performance of 3.1-9 is better
than 3.1-6, and that a determined user who _wants_ literal \r can disable
the shopt.
One of the remaining issues in my mind is the following. I have no
problem making igncr the default for bash, since there are no standards
stating what bash may or may not do. But I'm not sure whether making
igncr the default in 'bash --posix', aka '/bin/sh', is wise, since POSIX
does not permit this behavior. My only concern is that by making igncr
cognizant of whether posix behavior is requested, people will start asking
'why does my script work with #!/bin/bash but not #!/bin/sh?'.
- --
Life is short - so eat dessert first!
Eric Blake ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFJGBg84KuGfSFAYARAvErAJoC9FFPPnk50RzLnJsDGHknEpsPNACfUK4n
Pl1ovb1MWm6fPYbD2nwE3hM=
=fu4P
-----END PGP SIGNATURE-----
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -