This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash 3.1.17(8): Scripts on textmode mount get problems with CR characters

Hash: SHA1 - forwarding to the list accordingly.

> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com
                    ^^^^      ^^^^^ - munged accordingly. - reformatted accordingly.

>> I get:
>> Bash is broken in /home/pmb
>> Bash is broken in C:/Temp
>> Bash works in /tmp
>> Or have I overlooked something?
> You overlooked bash-3.1-9, which special cases DOS paths to ensure that
> the underlying mount path settings are honored even when you go behind
> cygwin's back by using DOS paths.
> You also overlooked several weeks' worth of discussions of this very
> issue on this list, including mail from me stating that I am considering
> preparing bash- 3.1-10 with the new igncr shopt (possibly turning it
> into an -o setting, so that $SHELLOPTS can affect it) on by default,
> instead of off by default; as igncr is definitely faster for \r\n
> handling than bash-3.1-6 ever was.

According to Bruun, Peter Michael (HP C&I CME OSS CoE) on 10/24/2006 8:33 AM:
> Hello Eric,
> Thanks for your help - however, I have not found that bash-3.1-9 solves
> the problem.
> I installed bash-3.1-9, and did:
>   mount -t \\C:\cygwin\home /home

Attaching the 'cygcheck -svr' output would confirm whether your mounts are
as you claim.

> As I have scripts in /home which har CRLF terminated, this is necessary
> in order to execute the scripts.
> My test script now outputs:
> Bash is broken in /home/pmb
> Bash works in C:/Temp
> Bash works in /tmp  
> The reason that C:/Temp now works is that this time I did not text-mount
> the C: drive.
> The shopt igncr makes no difference.
> As you may remember, what I do is:
>   F=`cat f.txt`

igncr does not affect command substitution (yet).  I am working on
bash-3.2-4 that extends the effect of igncr into `` and $().  Meanwhile,
have you tried setting IFS to include \r as one of the characters it
splits on?

> Where f.txt resides on the different directories. When assigning the
> value to F, bash is supposed to ignore the trailing newline that my file
> contains. But at the point of assigning the value to F, bash most likely
> no longer knows the origin of the value being assigned, and so the CR
> still causes non-conformance to standard behaviour of the assignment.
> By mounting /home as text, I guess that when cat and other tools read
> the file they should not pick up the CR preceeding the LF, but
> obviously, cat does.

cat forces a binary read of the file, regardless of the mount point.  At
one point (coreutils 5.2.1 days), upstream coreutils maintained a --binary
option to cat, but decided it was not worth maintaining, and in 5.90, cat
was changed upstream to always be binary.  Maybe it is time for me to
consider adding a cygwin-local patch that adds a --text option to cat, to
allow reading a text file without \r?

> I am probably still overlooking something?

There is always d2u:
F=`cat file | d2u`

> Best regards,
> Peter Michael Bruun (HP C&I CME OSS CoE)

- --
Life is short - so eat dessert first!

Eric Blake   
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]