From: earnie_boyd AT yahoo DOT com (Earnie Boyd) Subject: RE: echo is wrong... 17 Apr 1998 09:27:38 -0700 Message-ID: <19980416130921.9958.rocketmail.cygnus.gnu-win32@send1e.yahoomail.com> Reply-To: earnie_boyd AT hotmail DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Andrew Dalgleish , gnu-win32 AT cygnus DOT com ---Andrew Dalgleish wrote: > > 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) > (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 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) > > moreB > 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 AT hotmail DOT 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 AT cygnus DOT com" with one line of text: "help".