X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.1 required=5.0	tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RCVD_IN_SORBS_WEB,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
From: "James Johnston" <JamesJ AT motionview3d DOT com>
To: <cygwin AT cygwin DOT com>
References: <020501cd23f2$20f07620$62d16260$@motionview3d.com> <20120427143753 DOT GO25385 AT calimero DOT vinschen DOT de> <025501cd24c6$6a353990$3e9facb0$@motionview3d.com> <4F9B38FB DOT 9030607 AT dancol DOT org> <20120428052727 DOT GA23749 AT ednor DOT casa DOT cgf DOT cx> <4F9BD262 DOT 2000403 AT dancol DOT org> <4FAABEAE DOT 7000309 AT tlinx DOT org> <053b01cd2e18$f3f9ce60$dbed6b20$@motionview3d.com> <20120509201147 DOT GD22015 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20120509201147.GD22015@ednor.casa.cgf.cx>
Subject: RE: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
Date: Thu, 10 May 2012 16:28:14 -0000
Message-ID: <054d01cd2ec9$e6f4f5d0$b4dee170$@motionview3d.com>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> 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 pipe, and then setting up the pipe between the
two processes exactly as you outline.  Again maybe I'm naive, but to do what
I mention:

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).
2.  Bash and other shells would need a platform-specific patch to do the
checks I described: if piping to a non-Cygwin program, then use the special
Cygwin function for making byte pipes.

But that would require patching upstream shell with a platform-specific
change.  Any other code in packages that might pipe data to a non-Cygwin
process would need patching too (although, I cannot at the moment think of
anything besides a shell).  The bright side is that it's a local solution to
a local problem - no global variable that might adversely affect other code.

> [cat] doesn't know (and shouldn't know)
> what's on the other end of the pipe and that it should be changing the
mode
> of the pipe.

Agree 100%; the previous message wasn't meant to imply otherwise.

> 1.7.15 will contain a new CYGWIN option "pipe_byte" which will force non-
> tty, non-fifo pipes to use byte mode.  That's about as far as we're
willing to
> modify Cygwin for this apocalyptic problem. 

Thanks - I guess that will address the immediate issue in practice, although
it's a global solution to a local problem - though I don't see a way around
it without patching the shell itself.

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 starts" - which I assume includes parsing and using CYGWIN option?
Is it: (1) the variables are processed the first time CYGWIN1.DLL is loaded
into a process, and then never used again thereafter, or (2) every time a
process linking with CYGWIN1.DLL loads - even if CYGWIN1.DLL is concurrently
loaded by someone else?  I would assume it is #2....

Or to phrase another way: does Cygwin "start" once when the first process
linking to it is loaded, or does it "start" every time a process loads?  (I
realize Cygwin has extensive IPC and shared memory mechanisms, some of which
is probably done only on first load of first process to initialize shared
memory, which is what prompted this question.)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple