[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





Reply via email to