xterm is a console program?

[Harold L Hunt II]

  >>The console application has a console (which it may detach, but this 
also
>>detaches it from the running cmd.exe)
>>The GUI window has no own console but can create one. But this is not
> 
> connected
> 
>>to the starting cmd.exe.
>>
>>On linux the output of the program goes either to a logfile, the console
> 
> from
> 
>>where the X11 session was started or to /dev/null. On linux this very
> 
> easy.
> 
> In other words, on Linux (and the various Unices out there), starting an X
> app does *not* cause a new console to be created.  Said app will re-use its
> parent's console or use /dev/null.  Ergo, the same ought to be made true on
> Windows.
> 

Yes, I saw The Matrix Reloaded too, and I have had to resist using 
"ergo" in daily conversations since then :)  Have you seen it, or is 
this usage completely unrelated?

> Unfortunately, on Windows, for an application to send output to its parent
> console, it must be a console application and must be spawned into the same
> process group.  A negative side effect of this is that if such an
> application is an X app, and is spawned from anywhere other than a console,
> Windows will allocate a console on its behalf.
> 
> So we have a catch-22; either the program is made a console application, in
> which case it will have a console appear (bad), or it is made a GUI
> application, in which it will never be able to output to its parent's
> console (also bad).
> 

Actually, I don't think we have a chicken before the egg problem here... 
I think a more appropriate term would be SNAFU ;)

> The current way to break out of the catch-22 requires human intervention:
> rather than running the app you want to run, run "run" instead, and let
> "run" run the app you want to run.
> 
> My suggested break-out requires no human intervention other than an update
> to some library: have each X app detect that the only reason it has a
> console is that Windows allocated one for it and hide the console in such a
> situation.
> 
> The only other approach I can see is to find a way to find the parent
> process and somehow connect to its console.  I posted a link to a system
> internals utility that can find the parent process, but that still leaves
> connecting to its console an open problem.  Unless that console is a cygwin
> app, in which case you could create some kind of IPC endpoint in the cygwin
> dll to handle this, a very messy proposition, IMHO, that was rightly
> rejected.
> 

Just to clarify, it sounds like your new idea does not require any sort 
of environment variable.  That is correct, no?

> 
>>The evil hack is to include the code into the X11 library. This is the
> 
> last
> 
>>place where I want to see code that detaches the console. The correct
> 
> place
> 
>>is in cygwin1.dll, in the startup code. And this issue should be discussed
>>on the cygwin-devel mailing list.
> 
> 
> I originally thought about it going in cygwin1.dll but dismissed that before
> posting. The reason was that if you put it in cygwin1.dll, then any cygwin
> app would drop its console if launched in this manner, including non-X
> clients like bash.  That would clearly be Wrong so I suggested having it in
> the X11 client library.  I'm still unconvinced that the X11 client library
> is the appropriate place for this, but I haven't seen any better
> alternatives suggested yet.

I agree that the X11 library is, so far, the best place to put this sort 
of glue.

Lets turn down the flames on our gas grill here and see some code.  I 
think the discussion of why this is good or why this is bad is pretty 
much over.  Now I want to *see* what happens when we actually try this 
code in a test version of the X11 library for Cygwin/XFree86.  I am a 
very pragmatic person --- if no problems materialize, I am apt to go 
with the solution.  On the other hand, if it blows up in our faces then 
it will be obvious to all that another solution must be found.

So, can you send in that X11 lib goodness for all to see?


Thanks for contributing,

Harold