Re: stty & signals

[clintp]

Signal handling propogating to children? Okay mental exercise for you. If you've got a perl script with a signal handler like this:

   sub foo { }
   $SIG{TERM}=\&foo;
   fork() || exec("newprogram");

From newprogram's perspective, what's supposed to happen when a sigterm comes along? Jump back into the parent process' signal handler? Go looking for a foo of it's own? Segfault? :)

Signal handlers stay put during a fork(), but during the subsequent exec() they're reset to their default values. (And if you're exec'ing a shell, it's likely they're adjusted further even then.) The system() function essentially does a fork and exec to accomplish what it needs, so you're going to lose your signaling information.

A better place to start looking is to take away the suspend key (break, eol, etc..) and that'd be by going through the termios interface (or whatever the kids call it now). Some things that deal with that are: POSIX, Term::ReadKey (examples), ioctl, and calling stty to change the terminal's properties.

[steves]

This is not necessarily 100% true even though I agree with the logic of your mental exercise. Although it is system dependent, check you local *nix docs: On many systems, signals are only set to their default handler values if the process calling exec is catching them. Otherwise (e.g., if the calling process has them set to ignore) those settings are often carried across the exec call. The Solaris docs for exec(2) say this for example:

 
    Signals that are being caught by the calling
    process are set to  the  default  disposition  
    in the new process image (see signal(3C)). 
    Otherwise, the new process image inherits the
    signal dispositions of the calling process.

What this has meant on every system I've worked on is that process settings of ignore or default, even if different from the defaults, are carried across the exec call.

Strange to me that Perl would override default behavior for SIGSTP -- I'd think it would just pick up what the system specifies by virtue of calling the system's fork/exec sytem calls. So check your docs on these and see if SIGSTP is defined as being reset to its default across either fork (doubtful) or exec (more likely but not on the Solaris system I'm on here at work). Since you're setting it to IGNORE, that would be carried across the exec call on my system.

Signals are very system dependent though, so no surprise if that's not true for you.