Any thoughts on bug 1142?
Paul Smith
psmith at netezza.com
Wed Jan 10 06:26:44 PST 2007
On Wed, 2007-01-10 at 13:31 +0100, Jean Wolter wrote:
> Paul Smith <psmith at netezza.com> writes:
>
> > Anyone have any thoughts on this bug:
> >
> > http://bugs.busybox.net/view.php?id=1142
>
> busybox ash is derived from dash which has the same problem.
>
> dash-0.5.3/src> ./dash -c 'if set -o barfoo 2>/dev/null; then echo foo; else echo bar; fi'
> dash-0.5.3/src>
>
> Maybe it would be a good idea to forward this bug report to the
> authors of dash and integrate the fix to dash into busybox ash.
Thx. for the info Jean.
I poked through the code with my debugger and I see what's going on.
When you use "set -o blah" the shell does report a sh_error() with an
error message. It uses setjmp/longjmp to emulate exception handling,
and the sh_error() will print the message (I redirect it to /dev/null
above but it would be printed if I didn't) then longjmp() back to the
main loop.
In the main loop there's an if-statement:
shells/ash.c:7923:
if (e == EXEXIT || s == 0 || iflag == 0 || shlvl)
exitshell();
The error code (e) is not EXEXIT, it's EXERROR. However, the
interesting bit here is the "iflag == 0"; if the shell is
non-interactive, regardless of the setting of any other flags, then we
exit the shell.
If I run an interactive shell and use the same command the shell doesn't
exit, of course: it gives me another prompt just as you'd expect.
I think this test for interactivity is too broad: it seems quite obvious
that not every error exception in a non-interactive shell should cause
the shell to exit.
This seems like it could be a larger can of worms than I first imagined,
unfortunately.
More information about the busybox
mailing list