[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
