Greetings, Corinna Vinschen!
That has nothing to do with Cygwin. This is just how the environment is
handled in general. Child processes inherit it from their parent
processes, regardless whether on Windows or Unix.
Windows have means of notifying running processes about changes in global
The cygwin DLL can't intercede here. It's not some superior process
controlling I/O. It's just a DLL used by two programs. cat is writing to
the
stdout that it inherited from the shell.
Good point, I had not thought this through enough. In this case, bash.exe
is asking CYGWIN1.DLL for a
Hi James,
1. Cygwin would need an additional function with a parameter to specify
byte pipes (maybe you already added this, I have not checked the recent
source code very much).
You just missed the announcement:
On 2012-05-10 08:28, Corinna Vinschen wrote:
[snip]
I just released 1.7.15.
On Thu, May 10, 2012 at 12:28 PM, James Johnston wrote:
Forgive me for asking perhaps a dumb question, but I was reading the page at
http://cygwin.com/cygwin-ug-net/setup-env.html and wasn't too sure what was
meant by the sentence All Windows environment variables are imported when
Cygwin
On May 10 13:57, Earnie Boyd wrote:
On Thu, May 10, 2012 at 12:28 PM, James Johnston wrote:
Forgive me for asking perhaps a dumb question, but I was reading the page at
http://cygwin.com/cygwin-ug-net/setup-env.html and wasn't too sure what was
meant by the sentence All Windows environment
On 5/9/12 1:11 PM, Christopher Faylor wrote:
Please stop thinking that there is a simple solution that you can
intuit without fully understanding how Cygwin works.
Indeed. _Everything_ is more complicated than it looks.
1.7.15 will contain a new CYGWIN option pipe_byte which will force
James Johnston wrote:
I can't say with 100% certainty, but I would bet with 90+% confidence that
this
is a bug in MS's libraries -- they cheat and use a null/0 byte read as a
signal for end of file rather than sending out-of-band information that *nix
supports.
From examining .NET Framework
Daniel Colascione wrote:
On 4/27/12 10:27 PM, Christopher Faylor wrote:
The above comment shows an and relationship here. Message type pipes
more closely mimic Linux (UNIX) pipe behavior AND are definitely
required for ptys.
Yeah, but because message pipes break other programs. Cygwin has
-Original Message-
Sent: Wednesday, May 09, 2012 19:00
Subject: Re: Cygwin passes through null writes to other software when
redirecting standard input/output (i.e. piping)
I can't say with 100% certainty, but I would bet with 90+% confidence that
this
is a bug in MS's libraries
On Wed, May 09, 2012 at 07:21:34PM -, James Johnston wrote:
On Wed, May 09, 2012 at 11:59:58AM -0700, Linda Walsh, the dead discussion
resurrector wrote:
I can't say with 100% certainty, but I would bet with 90+% confidence
that this is a bug in MS's libraries -- they cheat and use a null/0
On 4/27/12 10:27 PM, Christopher Faylor wrote:
The above comment shows an and relationship here. Message type pipes
more closely mimic Linux (UNIX) pipe behavior AND are definitely
required for ptys.
Yeah, but because message pipes break other programs. Cygwin has only
been using message
On 26 April 2012 22:18, James Johnston jam...@motionview3d.com wrote:
I have run into an issue with Cygwin. This is arguably not a bug in
Cygwin, but in other platform runtime libraries. Never-the-less, the
symptoms occur only with Cygwin and not the Windows command prompt. So,
from a
-Original Message-
Sent: Friday, April 27, 2012 00:17
Subject: Re: Cygwin passes through null writes to other software when
redirecting standard input/output (i.e. piping)
Nope, it won't always be that because I get what's expected. I built the
C++
files using mingw g++. Although
On Apr 26 21:18, James Johnston wrote:
I have run into an issue with Cygwin. This is arguably not a bug in
Cygwin, but in other platform runtime libraries. Never-the-less, the
symptoms occur only with Cygwin and not the Windows command prompt. So,
from a practical standpoint, Cygwin is
On Fri, Apr 27, 2012 at 10:08:23AM +0100, cygwin-alanhowells.e4ward.com wrote:
Christopher Faylor says
Nope, it won't always be that because I get what's expected. I built
the C++ files using mingw g++. Although I actually expected the reader
to honor the null byte, it did not. Perhaps you
On 2012-04-27 AM 9:17, Christopher Faylor wrote:
There's no way that Cygwin could know to skip a call to WriteFile().
Cygwin doesn't interpose itself in the middle of a pipe. That would be
truly disastrous. If it somehow looked at every pipe read/write rather
than just allowing I/O to flow
On Fri, Apr 27, 2012 at 02:26:13PM -, James Johnston wrote:
On Thu, Apr 26, 2012 at 08:17:18PM -0400, Christopher Faylor wrote:
Nope, it won't always be that because I get what's expected. I built
the C++ files using mingw g++. Although I actually expected the reader
to honor the null byte,
On Sat, Apr 28, 2012 at 12:11:35AM +0900, jojelino wrote:
On 2012-04-27 AM 9:17, Christopher Faylor wrote:
There's no way that Cygwin could know to skip a call to WriteFile().
Cygwin doesn't interpose itself in the middle of a pipe. That would be
truly disastrous. If it somehow looked at
-Original Message-
Sent: Friday, April 27, 2012 14:38
Subject: Re: Cygwin passes through null writes to other software when
redirecting standard input/output (i.e. piping)
What I don't grok is this:
In your example, A and B are both native (== non-Cygwin) applications.
As I
On 4/27/2012 3:38 PM, James Johnston wrote:
So I think for sure, Cygwin's use of message pipes is breaking a lot
of Windows software, because of the null writes. And ALSO additionally
perhaps because of this: while reading MSDN today, I came across an
interesting snippet that probably
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
I have run into an issue with Cygwin. This is arguably not a bug in
Cygwin, but in other platform runtime libraries. Never-the-less, the
symptoms occur only with Cygwin and not the Windows command prompt. So,
from a practical standpoint, Cygwin is broken. This is almost certainly
the same
On Thu, Apr 26, 2012 at 09:18:27PM -, James Johnston wrote:
== SenderC.c: Sender program in Visual C++ 2008 ==
#include windows.h
int main() {
char * test = Hello world!\n;
DWORD written;
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE); /* Get standard output
23 matches
Mail list logo
