This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: echo is wrong...


Ernie Boyd writes:

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

Well, it would also be reasonable to always do translation to the native
file system format when writing to a pipe and translation from the native
file system format when reading from a pipe.  That is, let the pipe have
a binary/text mode on both ends, just as if it were any other file descriptor.

When writing to it, if the write end is in binary mode, simply pass straight
through.  If it's in text mode, then translate LF to CR LF, just as if you
were writing to a "real" file.

On the read side, if the read end is in binary mode, pass the data straight
through.  If it's in text mode, then translate CR LF to LF.

The translation is (I suppose) in the cygwin layer just above actual file I/O,
so this functionality isn't really in the pipe at all, it's in the generic
file I/O code.

The problem here, though, is in determining what mode to put each end of the
pipe in.  For normal files, the text=binary hack lets people force everything
to binary mode, but since pipes don't appear to be in a particular filesystem,
this doesn't help.  Somebody was suggesting a pipemode environment variable,
which could also work.  Personally, I think that files and pipes should
support text and binary modes and the programs writing text to files set in
binary mode should be fixed (ignoring the problem of programs that cannot
know if a file is text of binary for the time being...)

marcus hall


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



----- End Included Message -----


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]