Mail Archives: cygwin/1999/10/22/15:10:25
> -----Original Message-----
> From: Jon Leichter [mailto:jon AT symas DOT com]
> Sent: Friday, October 22, 1999 1:34 PM
> To: cygwin AT sourceware DOT cygnus DOT com
> Subject: RE: B20.1: CR-LF translation not always handled properly
>
>
<skipped>
> - 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
etc...
'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
this purpose).
Hope this helps clarify what the problem is; I think cygwin1.dll is OK, but
'sh' is not.
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux AT microprocess DOT com
b DOT dautrevaux AT usa DOT net
--------------------------------------------
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -