RE: echo is wrong...

[Earnie Boyd <earnie_boyd at yahoo dot com>]

---Andrew Dalgleish <andrewd@axonet.com.au> wrote:
>
<snip>
> 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).

I disagree with this.  The pipe is a facilitator of data output from
one process to be input to another process.  It's purpose dictates
that their should be no processing of the data through the pipe.

> The characters which get passed through a pipe should be exactly the
> same as the characters which would be written to a file.

The characters which get passed through a pipe should be exactly the
same as the characters which were _READ_ from a file.  No special
translations of any of the characters should be done via the pipe.


> This means translating end-of-line when reading and writing to a pipe,
> but *only* if a tool opens the pipe in text mode.

The "tool" is bash and "text mode pipes" are frankly incorrect for
this "tool".

> 
> 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)
> 

What does your use of MSDOS tools have to do with this thread?  The
discussion was concerning BASH not CMD?

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

> (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.)
> 

Exactly what was said, the "fix" was to change the open mode of the
pipes in BASH.

> 
> 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.

What about your first example?  It got an end-of-file with ^Z.  As for
the rest of your examples with ^Z it only proves that even CMD is
using "binary mode" for pipes and redirects.

> 
> 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.

Yep.  Works pretty well.

> 
> Regards,
> Andrew Dalgleish
> 

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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