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

List:       busybox
Subject:    Re: [BusyBox] CONFIG_FEATURE_SH_STANDALONE_SHELL broken?
From:       Rob Landley <rob () landley ! net>
Date:       2003-10-30 15:31:29
[Download RAW message or body]

On Wednesday 29 October 2003 21:55, Rob Landley wrote:
> On Wednesday 29 October 2003 07:14, Florian Engelhardt wrote:
> > Is CONFIG_FEATURE_SH_STANDALONE_SHELL broken?
> >
> > I compiled 1.0.0-pre3 with it enabled, however:
> >
> > # ./busybox ash
> >
> >
> > BusyBox v1.00-pre3 (2003.10.29-12:48+0000) Built-in shell (ash)
> > Enter 'help' for a list of built-in commands.
> >
> > # help
> >
> > Built-in commands:
> > -------------------
> >         . : alias bg break cd chdir continue eval exec exit export false
> >         fg getopts hash help jobs kill let local pwd read readonly return
> >         set shift times trap true type ulimit umask unalias unset wait
> >         [ ash bunzip2 busybox bzcat cat chgrp chmod chown chroot clear
> >         cp df du echo gunzip gzip kill killall ln ls mkdir mknod more
> >         mv ps pwd reset rm rmdir sh sync tar test touch vi which zcat
> >
> >
> > # ls
> > ash: ls: not found
> > #
>
> For some reason, CONFIG_FEATURE_SH_STANDALONE_SHELL was broken a while
> back. What it used to do is fork and have the child process call
> run_applet_by_name to call the appropriate code from the running busybox
> executable.
>
> Now what it does is attempt to exec "/bin/busybox commandname", which
> serves no purpose I can see.  The command path doesn't get searched for any
> external executables, so a non-busybox version of the command you typed can
> never get called anyway, even if there is one in the path.  All shelling
> out to busybox at an assumed absolute path (when we've already got a
> perfectly good copy of busybox running) does is introduce the possiblity of
> the exec failing, which looks like what's happening for you.
>
> The exec can fail if:
>
> A) Busybox isn't at /bin/busybox because you installed it in a directory
> other than /bin (such as the root directory, /usr/bin, etc.)
> B) Busybox isn't at /bin/busybox because it's called something other than
> busybox (like /bin/sh, this being a logical thing to call a standalone
> shell).
> C) Busybox isn't at /bin/busybox because you did a chroot.
>
> There are probably many more ways this can break, and no gain in doing it
> that I can see since if you have something like gnu ls in the path, it
> won't get called unless it's named "/bin/busybox".  I have absolutely NO
> idea why this change was made.  I'm sure there's a reason, but there's a
> lot of obvious collateral damage and no obvious gain...
>
> The problem can be seen at about line 3700 or so of shell/ash.c.
>
> Rob

The damage, by the way, was this patch:

http://www.busybox.net/cgi-bin/cvsweb/busybox/shell/ash.c?r1=1.65&r2=1.66

The entire comment of which in version 1.66 of
http://www.busybox.net/cgi-bin/cvsweb/busybox/shell/ash.c
is this:

> Fix STANDALONE_SHELL and ALWAYS_WIN options, last_path_73 by Vladimir N.
> Oleynik

Define "fix".  What was wrong with the old version, and what is the bad 
heuristic in the new version trying to accomplish?  (What actual problem was 
being addressed here?)

Rob
_______________________________________________
busybox mailing list
busybox@mail.busybox.net
http://codepoet.org/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]