echo is wrong...

[Andrew Dalgleish]

> --[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.
> [Bob McGowan]
> You appear to be assuming that the application (more, cat or whatever)
> manipulates
> the pipe.  I don't know how MS Win systems (or DOS, for that matter)
> do
> it, but I do
> know that in UNIX shells (including bash) all I/O redirection is
> handled
> by the
> shell.  And the shell does not "know" whether the tool being used will
> want its
> data in binary or text mode.  Safest, I think, is to do binary mode
> for
> the pipe.
> Then at least the data is passed in a consistent way.
> [END]
> 
[Andrew Dalgleish]  
Sorry, I wasn't very clear with this.

How the I/O redirection is implemented has nothing to do with the
translation mode.

If you pipe the output of tool A which has text output into tool B which
has binary input:
Tool A calls fputs("foo\n", stdout), and translates it into "foo\r\n".
Tool B reads "foo\r\n", and doesn't translate it, so it reads "foo\r\n".
This is what I meant by a "binary pipe".

If you pipe the output of tool A which has text output into tool B which
has text input:
Tool A calls fputs("foo\n", stdout), and translates it into "foo\r\n".
Tool B reads "foo\r\n", and translates it into "foo\n".
This is what I meant by a "text pipe".

Upon reflection the pipe itself should always be completely transparent
(binary), regardless of the tools.
The text/binary translation should happen *within* the tool.

Any code which relies on it's I/O being in a particular translation mode
without checking or forcing the mode is just plain bad code.
The tool should *explicitly* set the translation mode (E.G. under MSC by
calling _setmode(_fileno(stdin), _O_TEXT)

If a tool is reading a stream of bytes it should use binary mode.
If a tool is reading lines of text it should use text mode, no matter
what the OS uses as it's end-of-line sequence.
Hence you could create your own OS which has "this line ends here:" as
it's end-of-line sequence, and the tools will still function as
expected.

If you need to pipe text into a binary-only tool, create a filter which
has text in, binary out, and translates the OS-specific end-of-line
sequence to "\n".
Under an OS whose end-of-line sequence is "\n"  this filter is a no-op,
but the text vs binary concept still exists.
Any tool (or shell script) which depends on this no-op is broken.

[END]

> [Bob McGowan]
> The whole point of this discussion is that the ^Z IS interpreted.  A
> binary file,
> containing an embedded ^Z character, read through a text mode file
> descriptor,
> will return EOF on reading the ^Z character.  This results in the
> "truncated" file
> problems that so many posters have been talking about.
> [END]
[Andrew Dalgleish]  
I stand corrected.
>From the MS source:
                if (*p == CTRLZ) {
                    /* if fh is not a device, set ctrl-z flag */

Note that "copy" and "type" are internal commands.
It's only internal commands which stop at ^Z.
The MS-supplied external commands (find.exe, sort.com, more.com, etc)
don't stop at ^Z.
Consistent in their inconsistency.

I suspect the entire ^Z thing is a hang-over from CP/M days.
CP/M records the file size in disk blocks, and pads to the end of a disk
block with 1A

[END]

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