This is all very interesting, and responds to a question that I raised -- but it's been overcome by events. In run-1.1.12, we no longer care whether the current process's (that is, run's) GetStdHandles are from a console or not -- not even in commented-out code.
Instead, we care whether the current process HAS a console at all. If it does, then we [++] open new inheritable handles to CONIN$ and CONOUT$, and pass those to the child. This means that 'run foo >/dev/null' (that is, redirecting run's stdout to /dev/null, and expecting foo's stdout to also be redirected) -- but I don't think it worked in the past anyway. Instead, what now happens is foo's stdout will unconditionally go to the CONOUT$ of the (hidden) console. (same deal with 'run foo >somefile' -- but again, I don't think that ever worked before). So, what's the effective difference between sending foo's output to /dev/null, and sending it to a hidden console? In both cases it never blocks, and is always writable (in the latter case, because the console's message handler always drains the queue). However, I appreciate all the info. If there are problems with run-1.1.12, then maybe [++] is the place to add in an additional check concerning the handles returned by GetStdHandle(), using code similar to the ideas expressed in this subthread. -- Chuck -- 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
