This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: xterm is a console program?
>>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