Re: Value of $? after signal

Re: Value of $? after signal

[Bart Schaefer]

On Sep 10, 10:50am, David Korn wrote:
}
[Bart wrote:]
} > [I just sent a very similar message to the zsh-workers list.]
} > 
} >        The  return  value of a simple command is its exit status,
} >        or 128+n if the command is terminated by signal n.
} > 
} > What does ksh do?
} 
} First of all, ksh uses
} 	256+signo
} for processes that terminate due to a signal.  Otherwise, there
} is no way to distinguish between a process that does exit(130)
} and one that terminated due to a SIGINT.

I was looking at this a bit more.  There are a couple of places in exec.c
and jobs.c where zsh tests (the equivalent of) `lastval & 0200' to decide
whether a child process got a signal.  That means a child that explicitly
calls exit(130) can fool zsh into interrupting a loop (jobs.c:338) or (I
think) "propagating" a signal to the entire process group (exec.c:1070).

To see the jobs.c problem, compare:

    yes | for x in a b c; do echo $x; (exit 2); echo $?; done

    yes | for x in a b c; do echo $x; (exit 130); echo $?; done

I haven't come up with an example for the exec.c issue, but it should be
something similar to the above (requires a loop on the right of a pipe).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Value of $? after signal

[Bart Schaefer]

The manual says under the "return" builtin:

     If return was executed from a trap in a TRAPNAL function, the
     effect is different for zero and non-zero return status.  With zero
     status (or after an implicit return at the end of the trap), the
     shell will return to whatever it was previously processing; with a
     non-zero status, the shell will behave as interrupted except that
     the return status of the trap is retained.  Note that the numeric
     value of the signal which caused the trap is passed as the first
     argument, so the statement `return $((128+$1))' will return the
     same status as if the signal had not been trapped.

This is the only reference I can find to "exit status == 128 plus signal"
in the zsh manual, but the bash2 manual says in the "simple command"
grammar:

       The  return  value of a simple command is its exit status,
       or 128+n if the command is terminated by signal n.

Both zsh and bash appear to do this, i.e. if you interrupt "sleep 10" with
a ^C (SIGINT), $? is set to 130 in both shells.

The odd bit is what happens when a command is stopped with ^Z (SIGSTOP) or
with any other stop-signal (STOP, TTOU, etc.).  In this case bash sets $?
to 0, but zsh sets it to the signal number -- not 128+n, but n.  So, e.g.,
if you ^Z mutt, which catches TSTP and then sends itself STOP, you get $?
set to 19; but if you ^Z any command that doesn't catch TSTP, you get $?
set to 20.

I guess the reasoning in zsh is to not add 128 if the command has not been
terminated, but still report the signal number?  Or was the intent to use
128+n and we simply forgot the 128 somewhere?  Does anybody remember how
we arrived at this behavior?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net