Mail Archives: cygwin/2010/02/10/03:57:22
>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=3D0,user,noumount,auto)
>> H: on /cygdrive/h type netapp (binary,posix=3D0,user,noumount,auto)
>> P: on /cygdrive/p type netapp (binary,posix=3D0,user,noumount,auto)
>> R: on /cygdrive/r type ntfs (binary,posix=3D0,user,noumount,auto)
>> S: on /cygdrive/s type netapp (binary,posix=3D0,user,noumount,auto)
>> W: on /cygdrive/w type netapp (binary,posix=3D0,user,noumount,auto)
>> X: on /cygdrive/x type ntfs (binary,posix=3D0,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 problem=
s. =A0The reason empty lines are giving you obvious grief is because the ca=
rriage return character is not seen as part of the line ending and is being=
interpreted as a command instead. =A0Unless you have a program named the c=
arriage 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 atta=
ched a simple script which was saved with Windows line endings and no empty=
lines. =A0If 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=3Digncr does help, so this is a general
> fix which can be applied by setting SHELLOPTS under Windows.
> True. =A0Too bad it is only a solution for Bash. =A0If I remember correct=
ly, 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 th=
e 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
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.
Regards,
Jurgen
--
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
- Raw text -