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