X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: Bash 3.1.9 and 3.2.4: igncr setting not effective for 'source'd  files
Date: Thu, 2 Nov 2006 19:03:36 +0000 (UTC)
Lines: 43
Message-ID:  <loom.20061102T194752-810@post.gmane.org>
References:  <2fc802c00610311212i7bcc6b06sca14c0fda6ac6346 AT mail DOT gmail DOT com> <45489E5A DOT 9030408 AT byu DOT net>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Eric Blake <ebb9 <at> byu.net> writes:

> According to David Picton on 10/31/2006 1:12 PM:
> > Unfortunately I have to report that both versions of bash don't
> > implement the igncr setting if
> > commands are read from a sourced file.
> 
> Thanks for the report.  I'll investigate it, and hopefully bash-3.2-5 will
> have it fixed; I need to reroll bash 3.2 anyways, since official patches 2
> and 3 have been issued upstream.

Yuck.  :(

Bash implements . (and source) differently than it does for reading normal 
scripts - it slurps the entire file contents into memory up front, then does 
its parsing from that string, rather than line-by-line reading from the file.  
The existing igncr patch works with line-by-line parsing, because you can 
enable or disable it and affect all subsequent lines since they haven't been 
read yet.  But when the entire file is read up front, this trick doesn't work.  
It would be trivial for me to patch . to ignore \r in a source'd file based on 
the igncr setting (ie. if igncr is set, force O_TEXT when opening the target 
of ., the way bash-3.1-6 did), but that is a) cygwin-specific (and I've been 
trying to keep igncr clean enough to propose upstream for use outside of 
cygwin), and b) not very granular (by the time bash is processing the source'd 
file, it is already too late to change igncr to have any affect on the rest of 
that file; you have to have igncr set up front before invoking source).  On the 
other hand, since the entire file is read up front, . was not suffering from 
the same speed penalty as regular files in bash-3.1-6, so the argument for 
keeping binary handling of a source'd file is a bit weaker.

I'll have to give it more thought, and maybe I can come up with a cleaner 
solution by hacking parse.y to honor igncr in the grammar, instead of at the 
file read time, but my hopes are not too high at the moment. (Did I mention 
that bison grammar hacking is not my strongest point?)  It may just end up that 
bash-3.2-5 has the simpler hack that igncr must be set before using source if 
you want the source'd file to ignore all its \r.

And while I'm at it, maybe I will figure out how to name my release bash-3.1.3-
5, so that the bash patchlevel is included in the cygwin release number.

-- 
Eric Blake



--
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/