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
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
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
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 envir
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
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.
> 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
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 n
> -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
&g
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
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 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 gian
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 indic
> -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
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
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
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 fr
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
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
> -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 t
On 26 April 2012 22: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, C
On Thu, Apr 26, 2012 at 09:18:27PM -, James Johnston wrote:
>== SenderC.c: Sender program in Visual C++ 2008 ==
>
>#include
>int main() {
> char * test = "Hello world!\n";
> DWORD written;
> HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE); /* Get standard output
>f
22 matches
Mail list logo
