On Sun, 12 Sep 2010, Denys Vlasenko wrote: > On Sat, Sep 11, 2010 at 9:31 PM, Cristian Ionescu-Idbohrn > <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
