From: andrewd AT axonet DOT com DOT au (Andrew Dalgleish) Subject: RE: echo is wrong... 16 Apr 1998 10:13:10 -0700 Message-ID: <91A8FD196436D1118EC2006008186C96074F05.cygnus.gnu-win32@server1.axonet.com.au> To: Bob McGowan Cc: gnu-win32 AT cygnus DOT com > --[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".