Output of cmdline progs (was: KDE and the executable bit)
hans_meine at gmx.net
Mon Jan 28 20:56:02 GMT 2008
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
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
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.
/ / ANS ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel