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. IIUC the only thing windows considers to be a console is the butt ugly and functionally crippled text window we're trying to avoid. > >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. Paul
