shell 'trap' woodoo :)

[Cristian Ionescu-Idbohrn]

On Sun, 12 Sep 2010, Denys Vlasenko wrote:

> On Sat, Sep 11, 2010 at 9:31 PM, Cristian Ionescu-Idbohrn
> <cristian.ionescu-idbohrn at axis.com> wrote:
> > This test script:
> >
> > ---8<---
> > #!/bin/sh
> >
> > set -e
> > set -u
> > #set -x
> >
> > trap 'wrapper_func' EXIT TERM INT
> >
> > other_func() {
> >        echo "in : other_func" >&2
> > # XXX:  if this doesn't fail, the expected exit status comes out after 'trap'
> > #       but, if it _does_ fail, the exit status of the failed command will
> > #       be returned, as errexit will step in.
> >        ls -al /foo/bar/baz || :
> >        echo "out: other_func" >&2
> > }
> >
> > wrapper_func() {
> >        echo "in : wrapper_func" >&2
> >        date +%s >/dev/null
> >        echo "1. : wrapper_func: listing traps" >&2
> >        trap
> >        echo "2. : wrapper_func: removing traps" >&2
> >        trap - EXIT INT TERM
> >        echo "3. : wrapper_func: listing traps again" >&2
> >        trap
> >        other_func
> >        echo "out: wrapper_func" >&2
> > }
> >
> > echo "running: $0" >&2
> > sleep 5
> >
> > exit 77
> > --->8---
> >
> > does not behave as expected if the shell is ash, hush or dash.
>
> Care to describe the symptoms?
>
> So far I see that hush simply don't support set -e and set -u,

Don't focus on that.  That's not a bug.  It's unimplemented features.

> and clears EXIT trap in tha handler. Second problem is fixed by:
>
> http://git.busybox.net/busybox/commit/?id=a110c90de2f56bf38de30972813f012d44042cb9

Great!

> > Bash on
> > debian unstable:
> >
> >        GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)
> >        Copyright (C) 2009 Free Software Foundation, Inc.
> >        License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> >
> > does TRT, though.
> >
> > All shells run the trap action twice when hitting C-c with trap on INT.
> > With signals removed in the trap action, only bash behaves, according to
> > my experiments.
>
> # sh --version
> GNU bash, version 4.1.7(1)-release (x86_64-redhat-linux-gnu)
>
> # sh z
> running: z
> ^Cin : wrapper_func
> 1. : wrapper_func: listing traps
> trap -- 'wrapper_func' EXIT
> trap -- 'wrapper_func' INT
> trap -- 'wrapper_func' TERM
> 2. : wrapper_func: removing traps
> 3. : wrapper_func: listing traps again
> in : other_func
> ls: cannot access /foo/bar/baz: No such file or directory
> out: other_func
> out: wrapper_func

I run the test with 'busybox_unstripped', not 'busybox'.  Can that explain
the difference?

> # ./busybox hush z
> hush: set: -e: invalid option
> hush: set: -u: invalid option
> running: z
> ^C
> in : wrapper_func
> 1. : wrapper_func: listing traps
> trap -- 'wrapper_func' EXIT
> trap -- 'wrapper_func' INT
> trap -- 'wrapper_func' TERM
> 2. : wrapper_func: removing traps
> 3. : wrapper_func: listing traps again
> in : other_func
> ls: cannot access /foo/bar/baz: No such file or directory
> out: other_func
> out: wrapper_func
>
> hush seems to be ok.
>
> # ./busybox ash z
> running: z
> ^Cin : wrapper_func
> in : wrapper_func
> 1. : wrapper_func: listing traps
> trap -- 'wrapper_func' INT
> trap -- 'wrapper_func' TERM
> 2. : wrapper_func: removing traps
> 3. : wrapper_func: listing traps again
> in : other_func
> ls: cannot access /foo/bar/baz: No such file or directory
> out: other_func
> out: wrapper_func
> 1. : wrapper_func: listing traps
> 2. : wrapper_func: removing traps
> 3. : wrapper_func: listing traps again
> in : other_func
> ls: cannot access /foo/bar/baz: No such file or directory
> out: other_func
> out: wrapper_func
>
> ash seems to be buggy (enters into a trap despite it being cleared).

Don't we all know that? Dash is also buggy, bash too, and hush is not
ready yet :(

No criticism here.  I really _do_ appreciate your work.  IMO, there's no
"right" or "wrong".  There's only "frustration", "insufficient" and
"usable".

> Did I miss something?

Don't know :(  Did you?

I _think_ I can imagine how frustrating it may be for you to maintain code
you did not write yourself.  Still, untill 'hush' is up to par, 'ash'
_needs_ maintenance.  All too many projects depend on it!  It's more work
for you, I _do_ see that, but it's also, IMO, a recognition you're doing a
terribly good job!  Thanks for that.


Cheers,

-- 
Cristian