Output of cmdline progs (was: KDE and the executable bit)

[Hans Meine]

On Montag 28 Januar 2008, Thiago Macieira wrote:
> An intermediary solution would be to use a sentinel process that sets up
> the PTY as expected, but at the first sign of actual terminal use
> (including but not limited to stdout/stderr output or attempt to read
> stdin), it would exec (without forking) konsole in a special mode that
> would take over and display the output.

That's what I was thinking about.  (Thanks for summarizing the interesting 
details of how terminals work.)  Actually, exec()ing konsole appears even 
more elegant than what I imagined.

> Drawbacks I can see:
> 1) more expensive initialisation

I thought so.  After initialising the sentinel, would it incur any further 
penalty?  OK, the first I/O would lead to konsole being started, but after 
that, would there be a difference to the program as started with terminal in 
the first hand?

> 2) applications that cause debugging output to be shown will actually get a
> terminal, each, even if they do open an X11 window.

I think this would be not the biggest problem - I would suggest to use the 
sentinel only in cases where KDE does not know at all whether the user wants 
a terminal app or not.

> 3) some applications decide on whether to show any output based on whether
> they are connected to a teletype or not -- this would circumvent that
> measure.

Right, but these are not common, are they?  I met only one or two of them and 
cannot even remember which ATM.  I would think that the sentinel would simply 
say "yes / terminal" and then open konsole.

> 4) terminals are a limited resource.

Ah, didn't think about that.  But with modern Linuxes and devpts, is that a 
real problem?  Right now, I cannot estimate how many of these programs would 
be blocking a PTY at once.  Probably, the worst case would be daemons started 
via the minicli and running in the background, never doing any terminal IO.

Do such daemons close stdin/out/err?  Would it be possible to free the 
terminal in that case?  (Hopefully.)
Would it be possible for the sentinel to stop listening and freeing the 
terminal after, say 1 hour?  (I guess not, since the program is already 
connected to it.)

> What Windows gets different from us is that each executable has the
> information on whether it uses the console subsystem or not. If you've ever
> developed a Windows application, you'll know this.

Oh yes, and that's so... unhandy.

> Or you've been surprised 
> at why launching graphical Qt application from the command-line produces no
> output, not even qDebug.

That even happened to a student of mine on OS X (no std::cerr in a Qt4 prog).  
I thought it was better there.

> Hey, suggestion for an ugly hack: ldd the target application. If it doesn't
> link to X11, open a terminal. (will obviously break for statically-linked
> apps)

Heh - this is not so bad at all! :-)  Let's reformulate: If the target is a 
binary app linked to X11, don't use the sentinel. :-)

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080128/1dc66e1c/attachment.sig>