[plug] Xterms and bash and stuff: or, mysterious vanishing windows and mysterious vanishing stdin

[Russell Steicke]

On Sat, Nov 09, 2002 at 01:03:04PM +0800, Cameron Patrick wrote:
> Hullo all,
> 
> There's something that's often confused me about the way that Linux handles
> programs launched in the background.  Most of the time, you can start an X
> program in the background by typing something like 'xemacs &' in an xterm,
> close the xterm, and the Xemacs will still be there[1].  Occasionally,
> though, it disappears in a puff of smoke and nothing is ever heard from it
> again. Does anyone know what causes this?

When you close the xterm, it sends a SIGHUP to the shell (actually, I
think it sends SIGHUP to the process group, of which the shell is the
leader).  It's up to each program how it responds to this; the default
action is to terminate.  You could try using nohup ie

  $ nohup xemacs &

nohup installs a SIGHUP handler that ignores the signal (ie SIG_IGN),
then runs the program you specify.  I just tried this with emacs (not
xemacs) and it didn't work.  Emacs may install its own SIGHUP handler.
You could run your program with strace to find out.  But it did work
with xfontsel.

Actually, I just discovered that nohup is a shell script, so you can see
how it works there.  The important thing is the line

  trap "" 1

which makes the shell and any subsequent children ignore SIGHUP.


> Another curiosity I've noticed with bash's job control is that sometimes, a
> backgrounded program will be stopped if it wants to write to the screen,
> but other programs won't.  For example, type 'yes &' and you will see a
> column of 'y's on your console until the end of its days (more or less)[2];
> but if you try something like 'mc &' or 'lynx &', you won't see a thing
> until you fg it.

I think the difference here is whether the program is job-control aware
or not.  Not sure of the details...


> But wait, there's more---some programs (like patch) seem to be able to ask
> questions interactively even though their stdin has been redirected to some
> other file.  How can does this work if patch doesn't have an open FD to
> read from the terminal with?  Magic?

They open /dev/tty.  The kernel notices this and arranges
open("/dev/tty",mode) to return a descriptor for the process's
controlling terminal.

> [2] Is there any way of stopping yes without killing it from another
> console?

Blindly type fg, then blindly type ^C.

If you can justify or tax-deduct the cost (~ $140) a _very_ good
reference for this type of thing is "Advanced Programming in the UNIX
Environment", by W Richard Stevens.  Ignore the age of it (published
1993), it's an extremely thorough text on exactly what the title says,
and all relevant to Linux.


-- 
Russell Steicke

-- Fortune says:
Many hands make light work.
		-- John Heywood