|
From: | Evan Driscoll |
Subject: | Re: Error when script uses CRLF line endings w/ if stmt |
Date: | Thu, 04 Feb 2010 23:54:51 -0600 |
User-agent: | Thunderbird 2.0.0.23 (Windows/20090812) |
Jan Schampera wrote:
driscoll@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 bseemed 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
[Prev in Thread] | Current Thread | [Next in Thread] |