X-Spam-Check-By: sourceware.org Message-ID: <45246060.9010500@byu.net> Date: Wed, 04 Oct 2006 19:31:12 -0600 From: Eric Blake User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Similar Bash 3.1.18 CR/LF Problem References: <20061004114807 DOT GE30609 AT trixie DOT casa DOT cgf DOT cx> <4C89134832705D4D85A6CD2EBF38AE0F7B137A AT PAUMAILU03 DOT ags DOT agere DOT com> <20061004232458 DOT GB14493 AT trixie DOT casa DOT cgf DOT cx> In-Reply-To: <20061004232458.GB14493@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com -----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 >> 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/