This is the mail archive of the
mailing list for the Cygwin project.
Re: Bash and CR/LF line-endings
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com, pbaillargeon at innobec dot com
- Date: Tue, 03 Oct 2006 20:06:36 -0600
- Subject: Re: Bash and CR/LF line-endings
- References: <4522B21D.firstname.lastname@example.org>
-----BEGIN PGP SIGNED MESSAGE-----
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 email@example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v22.214.171.124 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html