diff options
author | Herbert Xu <herbert@gondor.apana.org.au> | 2010-04-02 13:59:42 +0800 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2010-04-02 13:59:42 +0800 |
commit | 2533d0df20e871da156d80078b79d93c8c02f0ad (patch) | |
tree | 390e780fe63ac5c7c29869d18077a4587fac8b09 /src/jobs.c | |
parent | [BUILTIN] Use TMPDIR in mkbuiltins (diff) | |
download | dash-2533d0df20e871da156d80078b79d93c8c02f0ad.tar.gz dash-2533d0df20e871da156d80078b79d93c8c02f0ad.zip |
[BUILTIN] Make trap signal name/number errors non-fatal.
On Wed, Feb 24, 2010 at 10:23:34AM +0000, Peter Kjellerstedt wrote: > > there seems to be a problem with the trap implementation in dash > (tested with 0.5.4 and 0.5.5.1). If I specify a signal which is not > supported, the shell unconditionally aborts. E.g., I had expected > the following to print foo (like bash and zsh do): > > # dash -c 'trap "echo trap executed" UNKNOWNSIGNAL || echo "foo"' > trap: 1: UNKNOWNSIGNAL: bad trap > > This means I cannot write a construct like the following to take > advantage of the ERR signal which is present in some shells: > > trap "echo ERR trap executed" ERR 2>/dev/null || : > > I also checked the POSIX documentation, and quoting from > http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html > (exit status): "For both interactive and non-interactive shells, > invalid signal names [XSI] [Option Start] or numbers [Option End] > shall not be considered a syntax error and do not cause the shell > to abort." This patch replaces sh_error with a outfmt + return 1 in trapcmd so that these errors are no longer fatal. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'src/jobs.c')
0 files changed, 0 insertions, 0 deletions