Mail Archives: cygwin/2012/05/10/12:28:42
> 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
- Raw text -