Thanks! RE: A Favour...

[Greg Badros <gjb@cs.washington.edu>]

I want to thank all of you for your responses to my little experiment
regarding the guile "system" call (really more about your system's
"system" call than about guile, as guile uses that function directly).

To summarize, Linux, Linux/Glibc, FreeBSD, and NetBSD all lost the xterm 
when a Ctrl-C was given in the guile repl tty after (system "xterm &").
HP/UX and Sun Solaris did not.

Under solaris, here's what the process table looks like after starting xterm:

ps -efj

     UID   PID  PPID  PGID   SID  C    STIME TTY      TIME CMD
...
     gjb 11563     1 11563 11563  1 10:23:41 ?        0:00 xterm
     gjb 11538 11386 11538 11386  1 10:22:45 pts/11   0:02 guile
...


Note that the xterm's process group ID and session ID are separate from
the guile that started it.


However, on linux, we have:

ps auxj

 PPID   PID  PGID   SID TTY TPGID  STAT   UID   TIME COMMAND
...
    1  4674  4648  4412  p9  4648  S   11960   0:00 xterm
 4412  4648  4648  4412  p9  4648  S   11960   0:00 guile 
...

Here the xterm has the same sesion and process group IDs as the guile.
It also has the same terminal process group id.  When the Ctrl-C is sent
to the guile tty, the sigint signal also is going to the xterm (as
observed by an strace on that process).  My understanding of POSIX.2
(admittedly only from Steven's APitUE) is that system is supposed to
ignore SIGINT.  In any case, it's clear that enough of the different
platforms do not have the behaviour I expect.  Can anyone else shed any
light on this matter?  Any scsh/shell/job-control gurus reading?

Why do we care?  Many of you probably don't need to, really. I was
concerned because all the xterm-s that I started under scwm were dying
when I hit C-c on the scwm process (running in a tty for testing) that
started them.

In any case, I added `scwm-system' to base.scm, and suggest that you use 

(set! use-scwm-system-proc #t)

to make `execute' and `exe' both use `scwm-system' instead of `system'.
This is probably only an issue if you run scwm from a tty as I
mentioned.  See the procedure below.

Again, thanks for your help (I was glad to add lots of new names to the
THANKS file!).  I'd love to hear from anyone who can enlighten me on the
specifics of these inconsistencies.

Greg



(define-public (scwm-system cmd)
  "Run CMD using /bin/sh -c CMD and return the exit status.
The CMD is run synchronously, and Bourne-shell meta characters
are interpreted by /bin/sh.  E.g., to start CMD in the background,
use a trailing \"&\" character.  See also guile's `system', but note
that it may permit signals on the controlling tty to be seen
by children (observed on Linux, Free/NetBSD, but not on Solaris or HP/UX.
This may be a bug (not meeting POSIX.2 specifications)."
  (let ((child-pid (primitive-fork)))
    (cond
     ((< child-pid 0) (error "bad fork"))
     ((> child-pid 0) ;; parent
      (begin
	(cdr (waitpid child-pid))))
     (else ;; child
      (begin
	(setpgid 0 0)
	(apply execlp (list "/bin/sh" "sh" "-c" cmd)))
      ))))