RE: echo is wrong...

[Andrew Dalgleish <andrewd at axonet dot com dot au>]

> -----Original Message-----
> From:	Larry Hall [SMTP:lhall@rfk.com]
> Sent:	1998 April 13, Monday 23:53
> To:	earnie_boyd@hotmail.com
> Cc:	gw32
> Subject:	Re: echo is wrong...
> 
> At 05:13 AM 4/13/98 -0700, Earnie Boyd wrote:
> >---Larry Hall <lhall@rfk.com> wrote:
> 
<snip>
> >Why?  Who in there right mind would want anything but binary pipe
> >reads?  What purpose would text pipes give?  I can't think of any. 
> >Pipes should always just pass along any data received.  They should
> >never do anything with the data, including interpret a ^Z as the end
> >of file.
<snip> 
> I completely agree with you Earnie.  Not that I want to start up a
> text vs
> binary war again but I've always come down on the side of using
> binary.
> While there may be reasons why its beneficial to have "text" mode
> files,
> its not at all clear to me that there are any benefits whatsoever to
> having
> "text" mode pipes.  If there are some good reasons (and it might be 
> interesting to hear what people think these could be), its also not
> clear 
> to me that there are enough Win32 programs that would rely on "text"
> mode
> pipes to warrant the pain it causes all those who attempt to use the 
> Cygwin utilities.
[Andrew Dalgleish]  
Assuming you have text mode files, there is a very good reason for using
text mode pipes.
It is not a good idea to have a tool operate in two different modes (one
mode for reading from a file, one mode for reading from a pipe).
The characters which get passed through a pipe should be exactly the
same as the characters which would be written to a file.
This means translating end-of-line when reading and writing to a pipe,
but *only* if a tool opens the pipe in text mode.

Sounds complicated? It gets worse.
Even the plain vanilla Win32 tools are inconsistent.
(I'm running NT4 service pack 3 cmd.exe for these examples)

file A contains "123\n456\n" (8 characters)

type A >B
leaves B with 8 chars (123\n456\n)

more<A >B
leaves B with 10 chars (123\r\n456\r\n)

sort<A >B
leaves B with 8 chars (123\n456\n)

type A | more >B
leaves B with 12 chars (123\r\n456\r\n\r\n)

type A | sort >B
leaves B with 10 chars (123\r\n456\r\n)

More by luck than design, reading a LF delimited file in text mode is ok
on Win32 because both LF and CR-LF are translated into '\n'.
The main cause of problems is when you are passing a CR-LF delimited
file into a tool which is processing lines of text but uses binary mode
to read it (ie bad code which depends on such lucky coincidences).
In practice this does not happen very often, and is easily fixed by
piping through "tr".

(Perhaps we could tag each .EXE with an attribute to specify it's input
mode... Hmm... It would be easier to fix the bad code.)


The plain vanilla Win32 tools are just as inconsistent with ^Z.
What little documentation there is suggests that ^Z is only used to
terminate stdin coming from the console, and is NOT the end-of-file
marker when reading from a file or a pipe.
Remember that fgetc() returns an int so it can hold EOF, if ^Z was the
end-of-file then fgetc() would return a char.

file A contains "123^Z456\n" (8 characters, ^Z == 0x1A)

type A
displays "123"

more<A
displays "123-456"

type A|more
displays "123-456"

type A>B
leaves B with 8 chars (123^Z456\n)

type A|more>B
leaves B with 11 chars (123^Z456\r\n\r\n)

more<A >B
leaves B with 9 chars (123^Z456\r\n)

I would suggest that ^Z is *never* used for the end-of-file when reading
from a file or pipe.

I use text files, and on the few occasions I run into problems I remind
myself that cygwin32 is not unix.
It's great, but it's not unix, so I don't expect everything to work
perfectly.
But I am satisfied more often than I am not.

Regards,
Andrew Dalgleish

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".