RE: B20.1: CR-LF translation not always handled properly

[Bernard Dautrevaux <DAUTREVAUX at microprocess dot com>]

> -----Original Message-----
> From: Jon Leichter [mailto:jon@symas.com]
> Sent: Friday, October 22, 1999 1:34 PM
> To: cygwin@sourceware.cygnus.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@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com