Re: Fwd: Problems with line endings for shell scripts

[Jeremy Bopp <jeremy at bopp dot net>]

On 2/9/2010 2:41 AM, Jurgen Defurne wrote:
> To be more complete :
> 
> 1) These are the mount points on my portable :
> 
> C:/Documents and Settings on /home type ntfs (binary)
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> H: on /cygdrive/h type netapp (binary,posix=0,user,noumount,auto)
> P: on /cygdrive/p type netapp (binary,posix=0,user,noumount,auto)
> R: on /cygdrive/r type ntfs (binary,posix=0,user,noumount,auto)
> S: on /cygdrive/s type netapp (binary,posix=0,user,noumount,auto)
> W: on /cygdrive/w type netapp (binary,posix=0,user,noumount,auto)
> X: on /cygdrive/x type ntfs (binary,posix=0,user,noumount,auto)
> 
> They are all binary.
> 
> 2) The problem occurs only with EMPTY lines (^\s*$). All lines filled
> with commands
> execute without problem.

You're just lucky that your other lines aren't displaying obvious
problems.  The reason empty lines are giving you obvious grief is
because the carriage return character is not seen as part of the line
ending and is being interpreted as a command instead.  Unless you have a
program named the carriage return character ($'\r' as bash shows it),
you'll see bash complain that it cannot find such a program.

To demonstrate how things could go wrong for non-empty lines, I have
attached a simple script which was saved with Windows line endings and
no empty lines.  If you run this under bash on a binary mount you'll see:

cp: cannot stat `testfile1.txt': No such file or directory

There will be a file named testfile1.txt with a carriage return
character after the extension created in your current working directory.
 If you run using any of the methods mentioned to work around this
issue, you'll see no output and will have two empty files named
testfile1.txt and testfile2.txt.

> 3) The posted solution SHELLOPTS=igncr does help, so this is a general
> fix which can
> be applied by setting SHELLOPTS under Windows.

True.  Too bad it is only a solution for Bash.  If I remember correctly,
make doesn't care for Windows line endings in its makefiles either, but
I don't think there is any easy solution such as this to blindly ignore
the issue.

> Also note that in the past I have never had this problem, and my
> scripts and programs
> use a mix of CR and CRLF line endings.

My best guesses for what changed for you:

1) Different text editor used to edit your scripts.
2) Different version control tool used to manage/fetch your scripts.
3) Upgrade from a really old version of Bash to the current version.

-Jeremy

Attachment: badlines.sh
Description: Text document

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple