Re: Error when script uses CRLF line endings w/ if stmt

[Evan Driscoll]

[This is an combination of a couple of replies to the various emails
since last evening.]

Pierre Gaston wrote:
> cygwin's bash is patched and provides a special igncr shopt option.
> try shopt -s igncr

And with the ability to pass options to Bash on invocation with -o, this 
provides a better solution to my problem then what had come before. (I 
was already doing 'bash script' and not using a #! or similar, so 
changing to 'bash -o igncr script' is no problem.)

Thanks very much.


Jan Schampera wrote:
> Personally, I have no problem with the \n-only behaviour (which - in
> fact - is not Bash specific. Most programs that use text files have
> trouble when you change to the other world)

I'm not totally sure this is true. Sure, a lot of programs have 
problems, but a lot don't. Emacs can use either line ending standard; so 
can Vi (I think), and so can Visual Studio. So can GCC and MSVC's 'cl'. 
So can Antlr. So can Python. Even's CMD.EXE's 'type' builtin displays 
LF-only files correctly.

Then, many programs don't handle them per se, but *not* handling them 
doesn't cause much problem. grep, cat, and echo probably fall in this 
category.

Really the ones that *can't* tend, in my experience, to be programs 
based off of old-school Unix programs, like Flex and Bison (IIRC) and 
Bash. (The main exception to this rule is Notepad.) IMO these programs 
are universally buggy for this reason.


Greg Wooledge wrote:
> Well, the most literal reason is that the shebang (#!/program) line
> will not work with a carriage return.  This line is read as a comment
> by bash, but as a "use this program" directive by the underlying OS.
> The OS is going to try to run $'/program\r' and will not find it.
> Unless of course you made $'bash\r' a symlink to bash, and so on.

Like the previous response, my personal view is that's a bug in the 
underlying OS that should be fixed, not used as an excuse for bugs in 
Bash. :-)

Evan