Has CR/LF and cat problem with textutils-2.0 been solved?

[Bernard Dautrevaux]

> -----Original Message-----
> From: Fifer, Eric [ mailto:EFifer@sanwaint.com ]
> Sent: Wednesday, September 27, 2000 3:31 PM
> To: 'cygwin@sources.redhat.com'
> Subject: RE: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
	...
> >
> >This was my point.  We fixed ash to do the right thing and I've been
> waiting
> >patiently for the bash maintainer to fix bash as well.
> 
> Is it possible to get a better idea of what the "right thing" is?
> 
> + Perl has a similar backtick syntax, but is fine handling
>   binary data.  I think it would be wrong to cripple its
>   binary abilities by setting text mode on backtick input.
>   However, as cat works now, on a text mount this will fail:
> 
>     #!perl
>     $out = <<EOF;
>     hello
>     world
>     EOF
>     open(FH, ">foo");
>     print FH $out;
>     close(FH);
> 
>     $in = `cat foo`;
>     print "not ok\n" if($out ne $in);
> 

IMHO perl is wrong there: from a logical point of view (sorry I can't chek,
I don't have perl installed on Win32), $out should contain '\n' line endings
(after all PERL is a UNIX tool, so internally we can expect it to work the
UNIX style, or porting scripts will be a mess), then:

On a text mount FH will get '\r\n' file endings, that cat will preserve;
however the perl bactick *should* convert it to '\n' line endings (after all
we are handling TEXT in perl, isn't it?), so "$i eq $out"; so if PERL read
backtick output as text the program will work OK.

On a binary mount, everything is simpler: '\n' line endings everywhere :-)

The only problem I may see is that the script may be read from a binary
mount but contain '\r\n' line endings: in this case a 'quick' port of PERL
may get '\r\n' line endings from the here-document while still matching
'\r\n' to an end-of-line in the script proper (as this is probably two
different places to fix in the code); if this bug is present then th eabove
program should fail on a binary mount. 

So if the above program fails on WIN32 this *is* IMNSHO due to a bug (or
two) in perl.
 
> + On a text mount, this results in LF endings:
> 
> 	#!sh
> 	cat >foo <<EOF
> 	hello
> 	world
> 	EOF
> 
>   But, this has CR/LF endings:
> 
> 	echo hello >foo
> 	echo world >>foo
> 	

Yes but if backtick read in text mode, you get LF endings in `cat foo` and
that's the problem we are discussing here.

> + A text file on a text mount (CR/LF endings) and a text file
>   on a binary mount (LF endings) concatenated together.  The
>   current cat will result in a file with mixed CR/LF and LF
>   endings.
> 

Ditto

> + A binary file on a text mount copied into another file
>   (cat foo.exe >bar.exe).  This now works with the latest cat,
>   with the B20.1 cat it would have "translated" the file.
> 

That's why the proper behavior is the current cat, not the B20.1 one :-)
That's also why I think the backtick processing of bash should be checked
(and the one of PERL also IMO) to read in text mode whatever the mount or
the default is.

> Eric Fifer
> 

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
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