xterm is a console program?

[Harold L Hunt II]

Alexander Gottwald wrote:

> On Tue, 20 May 2003, Early Ehlinger wrote:
> 
>>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.
> 
> 
> It will always use the parent stdin/stderr/stdout (which might be the console).
> On Windows you don't have a parent stdin/stderr/stdout to attach, so Windows
> creates them with the console.
> 

Right, but Early is now talking about leaving the X apps as command-line 
apps so that they are attached to the parent processes console by 
default, and he only detaches the console if it becomes apparent if that 
console was created specifically for this process (such as when you 
double-click an X app in Windows Explorer).

> 
>>>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.  
> 
> 
> This is also wrong for a lot of X11 applications. Just imagine the debug 
> nighmare when the user never sees the "Can't connect to display" message
> and crys "xterm bombs!!!!! :( Plz Help" 
> 

Actually, this sort of fix would probably cut down on debugging 
problems.  The proposed fix wouldn't change what happens when you run 
xterm (or any other X app) from the command-line --- you would still see 
the output.  Most users are used to not seeing the output from the apps 
when they run them from the startup scripts, so the first thing they do 
when there is a problem is to run the busted app from the console.  In 
both of those cases the proposed fix would cause things to happen the 
way that the user expects them to happen.

> 
>>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.
> 
> 
> There is no general difference between an X11 app and any other cygwin app.
> There is also the sshd, which does not need the console but displays it. 
> 
> The only suitable place for such a functionality is cygwin1.dll. Maybe with
> a compiletime switch to force the program to keep the console (for bash,
> mutt ....). But this code does not belong into libX11 and I doubt that any
> member of the XFree crew will ever apply such a change to cvs.
> 

I like Chris's suggestion that this be made into a simple .o file that 
injects itself before main () when it is linked into an app, just like 
automode.o does.  Chris said he would even except this as a Cygwin 
package.  The only requirement for us would be to selectively link 
autocommandline.o with certain applications that it would be appropriate 
for.

See, we said before "X11 lib is the best place for now".  Now that we 
have continued discussing this a better idea has been presented, so lets 
move forward to that.

Harold