This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]