Mail Archives: cygwin/1998/04/16/10:13:10
> --[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 AT cygnus DOT com" with one line of text: "help".
- Raw text -