This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Problem with pex-win32.c


On Tue, Mar 14, 2006 at 07:59:22PM +0000, Paul Brook wrote:
>On Tuesday 14 March 2006 19:46, Ross Ridge wrote:
>> Dave Korn writes:
>> >I don't understand why you think Mark's code needs to search the PATH or
>> >append '.exe', when it invokes CreateProcess that does all that for you?
>>
>> I've already answered that question: "subtle differences in the other
>> behaviours could cause problems."  The search behaviour and extension
>> handling of CreateProcess() is actually quite a bit different than
>> of MSVCRT's spawn functions.  Also, because of the way he uses
>> CreateProcess(), Mark's code as it is now won't search the PATH.
>>
>> >> 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.
>>
>> Arguably, not having a console window attached a shell window is broken
>> in the Cygwin environment.
>
>How exactly do you suggest implementing this? I'm fairly sure the cygwin 
>people have concluded this is impossible.

No, we haven't.  We have, in fact, gone to great lengths to try to ensure
that a console is always attached to a tty/pty.

>>>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.
>>
>>So, in general you can't expect any Win32 console application to work
>>correctly in such a enviroment.  Why should Mark expect a Win32 console
>>version gcc to be any different?  Hmm...  maybe that's best solution,
>>Mark should be using a "native" Cygwin version of gcc and tools.
>
>By implication you're saying that you shouldn't able to use gcc from
>any GUI environment.  Cygwin isn't any different to any other process
>(eg.  Eclipse) that want to run and capture the output of "commandline"
>applications.

It is entirely possible that programs which look at their stdin/stdout
will be confused when running under a cygwin pty but they should not,
in theory, be confused if they try to detect if they have a console
attached because there *should* be an invisible console attached to
any process running in a pty.

cgf


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