> 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
