This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)

On Fri, Apr 27, 2012 at 05:25:31PM -0700, Daniel Colascione wrote:
>IIRC, it had something to do with preserving message boundaries at the
>TTY later. Again IIRC (and I only faintly recall this part) the PTY
>layer has to deliver one line at a time to readers. If a client calls
>read(2) with a giant buffer, he's still supposed to get back only a
>single line at a time. A message-mode pipe seems like a good way to
>provide these semantics because it preserves write boundaries --- so if
>you write only a line at a time, the reader reads only a line at a time.
>It's a shame that this approach causes problems.
>Why can't only pseudoterminal pipes be created as PIPE_TYPE_MESSAGE?
>Cygwin already has special logic to tell whether a handle it's opening
>is a pty and to treat it specially in that case.

Use the source code, Jake.  From

 Note that the write side of the pipe is opened as PIPE_TYPE_MESSAGE.
 This *seems* to more closely mimic Linux pipe behavior and is
 definitely required for pty handling since fhandler_pty_master
 writes to the pipe in chunks, terminated by newline when CANON mode
 is specified.  

The above comment shows an "and" relationship here.  Message type pipes
more closely mimic Linux (UNIX) pipe behavior AND are definitely
required for ptys.

Problem reports:
Unsubscribe info:

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