This is the mail archive of the
mailing list for the Cygwin project.
Re: Fwd: Problems with line endings for shell scripts
- From: Jurgen Defurne <jurgen dot defurne at gmail dot com>
- To: cygwin at cygwin dot com, Jeremy Bopp <jeremy at bopp dot net>
- Date: Wed, 10 Feb 2010 09:57:08 +0100
- Subject: Re: Fwd: Problems with line endings for shell scripts
>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.*
That will be the last one. We used to Cygwin 1.3, then switched over
to 1.5, but development
here decided to use MontaVista for development, which was (is?) still
based on Cygwin 1.3.
Since both environments together caused conflicts, we removed the
Cygwin 1.5 installations
and ran all our programs through the MV Cygwin environment.
Now we switched to Embedded Alley, which uses Mingw for the compiler,
and so finally we
can upgrade back again to Cygwin 1.7.
And this is what MV reports for bash :
GNU bash, version 2.05b.0(1)-release (i686-pc-cygwin)
Copyright (C) 2002 Free Software Foundation, Inc.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple