This is the mail archive of the
mailing list for the Cygwin project.
RE: B20.1: CR-LF translation not always handled properly
- To: "'Jon Leichter'" <jon at symas dot com>, cygwin at sourceware dot cygnus dot com
- Subject: RE: B20.1: CR-LF translation not always handled properly
- From: Bernard Dautrevaux <DAUTREVAUX at microprocess dot com>
- Date: Fri, 22 Oct 1999 21:08:41 +0200
> -----Original Message-----
> From: Jon Leichter [mailto:email@example.com]
> Sent: Friday, October 22, 1999 1:34 PM
> To: firstname.lastname@example.org
> Subject: RE: B20.1: CR-LF translation not always handled properly
> - At the command prompt, type the following:
> $ xx=`gcc -print-prog-name=ld`
> $ echo $xx | od -x
> This step ought to clearly show (by looking at the hex dump)
> that the xx
> variable has been set to the value "ld^M", which is completely wrong.
I agree, `` should read in text mode
> Now, try this:
> $ echo $xx | cat | od -x
> Notice no change.
This is correct. By definition 'cat' was expected to correctly handle binary
data, so it _must_ read the pipe in binary mode. No problem here; it's
execatly what it should be.
> Now try this:
> $ echo $xx | grep ".*" | od -x
> Notice that the ^M has (correctly) been stripped.
This is correct also; grep is handling textual data, so correctly set its
input pipe to read in text mode.
> Not only should 'cat' have done the right thing, but the
> orignal command
> substitution should never have ended up with the ^M character.
'cat' is ok, but bash (or ash, depending on what you use as /bin/sh) _must_
use text mode when reading the pipe used for command substitution. This
thread was already followed seevral times. I don't think theer is a problem
here with cygwin1.dll :-), but rather with bash/ash command substitution
> The Mingw32 tools produce ^M characters in its output, and there isn't
> anything that can be done about that. It is the
> responsibility of the Cygwin
> tools (especially the ones that process text) to make sure
> that stdin and
> stdout have been opened in textmode, and this simply does not
> seem to be
> happening with all of the tools.
And this is not only the case of mingw32. Using a Windows box mean we are
interested in accessing Windows resources. You'll get the same problems if
some Windows application generate a list of items and I try to handle it by:
for i in `cat windows-generated-file.txt`; do
'cat' is correct in handling 'windows-generated-file.txt' in binary mode as
he has no way to know its text; but the shell _knows_ it's text so it must
read it as text.
> Someone please try these tests and let me know if you see the
> same behavior
> that I have described.
I've seen this regularly and have found no other solution as filtering
through some '^M'-suppressing program (although I've not think at grep for
Hope this helps clarify what the problem is; I think cygwin1.dll is OK, but
'sh' is not.
97 bis, rue de Colombes
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
Want to unsubscribe from this list?
Send a message to email@example.com