This is the mail archive of the
mailing list for the GCC project.
RE: Problem with pex-win32.c
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Paul Brook'" <paul at codesourcery dot com>, <gcc at gcc dot gnu dot org>
- Cc: "'Ross Ridge'" <rridge at csclub dot uwaterloo dot ca>
- Date: Tue, 14 Mar 2006 19:29:46 -0000
- Subject: RE: Problem with pex-win32.c
On 14 March 2006 19:22, Paul Brook wrote:
>>> Is this really worth it? Could this whole problem be solved by you
>>> switching to rxvt? Maybe the only problem is that your xterm is broken.
>> Nothing is "broken". The problem is that Cygwin applications run in a
>> slightly special environment, where there may not be a console attached to
>> the shell window. This is not a problem for cygwin apps, but it can be for
>> non-cygwin-aware apps launched from inside cygwin's 'special' environment
>> that may assume that the standard win32 assumptions hold. This is a
>> consequence of cygwin providing features over and above the underlying OS:
>> software written for the underlying OS can't be aware of every possible OS
> The problem isn't unique to cygwin. The same problems occur in any
> environment that doesn't run inside a win32 console window. eg. most IDEs,
> including Eclipse and MS Visual Studio.
Well, cygwin knows about this, and takes steps when launching a new process
to not let it get confused if it doesn't have a console attached. Eclipse and
MSVC could do likewise. The problem really arises when cygwin has to launch a
new non-cygwin process; then there's nothing it can do to stop the child
getting confused and generating a new console.
Can't think of a witty .sigline today....