[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: printf without any argument exits ash
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2008-12-17 2:26:51
Message-ID: 200812170326.51809.vda.linux () googlemail ! com
[Download RAW message or body]

On Tuesday 16 December 2008 10:55, Michael Abbott wrote:
> On Wed, 10 Dec 2008, Denys Vlasenko wrote:
> > > But, when I run "printf" without any argument, it simply kills the shell
> > http://busybox.net/downloads/fixes-1.13.1/busybox-1.13.1-printf.patch
> 
> A couple of thoughts:
> 
> 1. This patch needs to be added to the 1.12 patches (it applies cleanly to 
> 1.12.3 without any modification).  Except...

Done

> 2. Eww.
> 
> Clearly the problem is that bb_show_usage() exits after showing applet 
> specific usage, but when it's called as a built-in from a shell this isn't 
> the right behaviour.  
> 
> I see, for example, that rm.c also claims to be a NOFORK applet (shouldn't 
> printf.c say so as well?), but it happily manages to call bb_show_usage() 
> without killing the shell.  Or is it lying about not being forked...?

Yes, NOFORK applets have magic for that.

> Sorry, I should be answering my own questions by inspecting the code -- 
> but I don't know my way around well enough.  For example, where is the 
> FORK/NOFORK status determined?

include/applets.h:

...
USE_AWK(APPLET_NOEXEC(awk, awk, _BB_DIR_USR_BIN, _BB_SUID_NEVER, awk))
USE_BASENAME(APPLET_NOFORK(basename, basename, _BB_DIR_USR_BIN, _BB_SUID_NEVER, basename))
...

> A quick dig is interesting.  If I take rm.c at face value, there's an 
> interesting discrepancy.  `rm` definitely shows usage without exiting 
> the shell, and clearly does so by calling bb_show_usage(), which 
> clearly exits by calling xfunc_die() ... which is where things get 
> interesting.  I'm not too sure about the context, but it looks to me as if 
> we *should* be exiting by a longjmp (which is what I was expecting).
> 
> Thus this begs the question: why didn't printf take the longjmp?

Because "printf-called-from-ash" is not a NOFORK, it's
a shell builtin.

Builtins do not use NOFORK magic. For one, because they
exist and work as builtins even if
CONFIG_FEATURE_SH_NOFORK and FEATURE_SH_STANDALONE are off.

> Surely  
> the patch should address that underlying problem rather than the nasty 
> local hack which we actually see!

Yep, there is some potential for unification between NOFORKs and builtins.
--
vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]