This is the mail archive of the
mailing list for the Cygwin project.
Re: Bash and CR/LF line-endings
- From: "Larry Hall (Cygwin)" <reply-to-list-only-lh at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 03 Oct 2006 23:04:20 -0400
- Subject: Re: Bash and CR/LF line-endings
- References: <000201c6e75c$97a8afe0$020aa8c0@DFW5RB41>
- Reply-to: cygwin at cygwin dot com
Gary R. Van Sickle wrote:
From: Eric Blake
Sent: Tuesday, October 03, 2006 9:07 PM
Subject: Re: Bash and CR/LF line-endings
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.
At the risk of being over-obvious, Linux users... use Linux. In such an
insular environment, perhaps they have the luxury of only using the One True
Text File Format (whatever that is). Actually, Windows users also have that
luxury, as long as they wish to remain in their own world as well. Where
the twain meet of course is where we run into issues, and the twain meet at
Cygwin. Used to, anyway.
Linux users use Linux until they are forced to use Windows. When that
happens, they tend to use Cygwin. Since Cygwin is intended to meet their
needs, it should do so in a transparent way whenever possible. But there's
cases where that isn't possible and, lo and behold, that's still in Cygwin.
So why was the solution of using the 1st line of the script
was claimed, is read anyway for other purposes) and base
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.
What's going to break if igncr is simply always on?
Me poor head! ;-)
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html