Message-ID: <4523172C.7090502@byu.net>
Date: Tue, 03 Oct 2006 20:06:36 -0600
From: Eric Blake <ebb9 AT byu DOT net>
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, pbaillargeon AT innobec DOT com
Subject: Re: Bash and CR/LF line-endings
References: <4522B21D DOT 8040505 AT innobec DOT com>
In-Reply-To: <4522B21D.8040505@innobec.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Pierre Baillargeon on 10/3/2006 12:55 PM:
> I've been wondering during this whole event why one of the original proposal
> was not used?
> 
> As far as I can see, the main problem with both latest bash revisions is that
> the solution to the cr/lf problem demands that users be either pro-active or
> gifted guessers. Both the d2u and the shopt solutions requires the user to
> understand that bash trashing about with incomprehensible  errors is due to
> bad line endings. This is compounded by the fact that those scripts may be
> lying in the middle of custom toolchains developed internally and used by
> non-programming end-users. Also, due to the previous more forgiving behavior
> and the nature of working in a Windows environment, the creeping of cr/lf is
> inevitable for some users. Add to this that both current solutions requires
> the modification of the scripts, Isn't it expected that it raised many red
> flags? Not counting those who are not inclined to read announcement and
> development mailing list and just install product and have it work
> out-of-the-box... I can see future new users figuratively throwing back cygwin
> in the trash-bin because it can't even run a simple shell script correctly.

Perhaps so, but that was a risk I was willing to take, since cygwin's
stated goal is to provide a Linux emulation on Windows, and Linux users
don't go creeping in cr/lfs.

> 
> So why was the solution of using the 1st line of the script (which, it was
> claimed, is read anyway for other purposes) and base the seeking behavior on
> the detection of cr/lf there, rejected?

It is not rejected, merely unimplemented.  My patches have focused on the
minimal amount of code to get a decent workaround, and hacking the initial
80-character read of a file proved harder than hacking the input engine.
If someone else (how about you?) were to submit a patch doing just that,
then I would certainly review it and likely apply a derivative of it, in
part because reviewing a patch is a much smaller time commitment on my
part than me writing yet another workaround from scratch.

Actually, if anyone is interested in pursuing this further, it may be
worth auto-setting the igncr shopt according to the first line of the
script, rather than the current behavior of defaulting that option to
unset for every new bash invocation.  Also, you must consider how things
should work when stdin is a pipe containing \r\n data, since with pipes,
you can't prescan the first line of input to see what it contains because
you can't rewind afterwards.

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

iD8DBQFFIxcr84KuGfSFAYARArACAKDQqVRU2wrpRYcfhhbKf9n/pzXkcgCfb6tf
w0ns04SUtcx9W+RcpjMIiHg=
=cHSI
-----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/