This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash and CR/LF line-endings

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

What's going to break if igncr is simply always on?

Me poor head! ;-)

Larry Hall                    
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]