Jan Schampera wrote:
drisc...@cs.wisc.edu schrieb:
Some of the time, using CRLF line endings cause syntax errors
in Bash scripts ("unexpected end of file").
This problem shows up on Bash 4.1 on Linux, Bash 3.2 on Linux,
and Bash 3.2 on Cygwin (where I first noticed it).
Normal. Though I don't know how to treat the Cygwin case, since the
underlying platform uses \r\n anyways. But the rest: Simply don't mix
UNIX and Windows text.
Why not make Bash consider \r\n a legitimate line ending? What possible
reason could there be for treating carriage return characters as it does
now?
For the curious, my use case is that I have a Bash script in a CVS
repository, but many people working on it use TortoiseCVS, which (unless
you take some steps otherwise) does endline conversion on
checkout/commit. This meant that checking out the file caused it to not
work with Bash. I worked around this by setting the script as a binary
file, but it still seems silly that Bash doesn't correctly deal with a
common newline convention. (I feel it's just as silly that Notepad
doesn't deal with LF endlines, but that's neither here nor there.)
(BTW, my earlier report was a bit misdirected. I posted it with the more
complex if statement thing because another example,
echo a
echo b
seemed to work with both CRLF and LF endings. However, further
experimentation confirmed what you probably already know, which is that
it only appeared to work; in fact what was happening is that the CR
character was being passed to echo as part of the argument, and it
didn't affect the output. In fact, if you put a space after the 'a' and
'b', echo receives two arguments beyond the command name: the 'a' or 'b'
as the first and ^M as the second.)
Evan Driscoll
