help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Asynchronous shell command that leaves a background process running


From: Sean McAfee
Subject: Asynchronous shell command that leaves a background process running
Date: Wed, 08 Dec 2010 15:32:38 -0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

I've written a shell script which is essentially a single exec command:

  #!/bin/bash
  exec real-program fixedarg1 fixedarg2 "$@"

"real-program" chugs along for several seconds, printing some status
messages in the meantime, before finally forking off a background
process and exiting.  The background process manifests a window on my
desktop.

All is well when I run this command from an interactive shell, but
things fall apart when I try to run it as an asynchronous shell command
from Emacs, a la:

  (shell-command "wrapper-script arg1 arg2 &")

I see the status messages appear in the *Async Shell Command* buffer,
but when the command exits, no desktop window appears.

The only fix I've found is to execute real-program in a separate process
group:

  #!/bin/bash
  perl -e 'if (fork() == 0) { setpgrp; exec @ARGV } wait' \
    real-program fixedarg1 fixedarg2 "$@"

I guess Emacs is sending a fatal signal (probably SIGHUP) to the
asynchronous shell's process group after the main process exits.

Naturally I don't want to have to write my scripts defensively against
the possibility of running asynchronously from Emacs.  So I can just
move my perl/setpgrp wrapper inside Emacs:

  (shell-command "perl -e 'if (fork() == 0) { setpgrp; exec @ARGV } wait' 
wrapper-script arg1 arg2 &")

That's pretty ugly, though.  A little Googling turned up the nohup
command, which also mostly does the job:

  (shell-command "nohup wrapper-script arg1 arg2 | cat &")

The "| cat" is necessary to prevent nohup from redirecting output to
nohup.out.  That's still ugly, and I also get the distracting header
"nohup: ignoring input and redirecting stderr to stdout" prepended to my
normal output.

Is there a more elegant way to address this problem?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]