executable if we asked to exec someting with argv[0] == known_applet"
Use it in init. Also respect PATH in init, remove explicit "/sbin" etc
from exec. Patch by Gabriel L. Somlo <somlo@cmu.edu>
things like xasprintf() into xfuncs.c, remove xprint_file_by_name() (it only
had one user), clean up lots of #includes... General cleanup pass. What I've
been doing for the last couple days.
And it conflicts! I've removed httpd.c from this checkin due to somebody else
touching that file. It builds for me. I have to catch a bus. (Now you know
why I'm looking forward to Mercurial.)
untangle them:
Rewrite u_signal_names() into get_signum() and get_signame(), plus trim the
signal list to that required by posix (they can specify the numbers for
the rest if they really need them). (This is preparatory cleanup for adding
a timeout applet like Roberto Foglietta wants.)
Export the itoa (added due to Denis Vlasenko, although it's not quite his
preferred implementation) from xfuncs.c so it's actually used, and remove
several other redundant implementations of itoa and utoa() in the tree.
moved the contents of libbb/bb_echo.c back into coreutils/echo.c,
which is a more reasonable place for them than libbb. this
forces anyone who wants echo and test to be builtin to ash to
also have them available as applets. their cost is very small,
and the number of people who wouldn't want them as applets is
also very small.
added warning about shell builtins vs. CONFIG_FEATURE_SH_STANDALONE_SHELL,
which conflicts with their use.
thanks to nathanael copa for debugging help.
some string size optimization in test.c may have been lost with
this commit, but this is a good new baseline.
Summary 0000242: ash: read -t broken
this also implements -n and -s options to read. (they're configured
together because most of their code is in common, and separating them
seemed silly.
If we exec /proc/self/exe and only fall back to /bin/busybox if /proc isn't
there, then we have a reasonable chance of having the standalone shell work
even if busybox isn't installed in /bin on the system in question.
Still won't work in a chroot environment, but it's an improvement.
CONFIG_FEATURE_COMMAND_EDITING was defined *and*
CONFIG_FEATURE_COMMAND_TAB_COMPLETION was undefined.
Vladimir N. Oleynik writes:
Its declare always, also if CONFIG_FEATURE_COMMAND_TAB_COMPLETION
undefined.
Patch to CVS version attached.
--w
vodz
On Wed Aug 18, 2004 at 06:52:57PM +0800, Matt Johnston wrote:
> I've come across some strange-seeming behaviour when running programs
> under Busybox (1.0.0-rc3) ash. If the child process sets stdin to be
> non-blocking and then exits, the parent ash will also exit. A quick strace
> shows that a subsequent read() from stdin returns EAGAIN (as would be
> expected):
Thanks!
Patch attached.
--w
vodz
With job control enabled, ash fails to tcsetpgrp back to initialpgrp
upon exit. exitshell() should call setjobctl(0) to do this.
Context: I am using a lightweight menu system (replimenu[.sf.net]) on my
console, which invokes "/bin/sh -i -c /bin/login", where /bin/sh and
/bin/login are busybox applets. /bin/sh is ash, with
CONFIG_ASH_JOB_CONTROL=y as the sole suboption. The shell of the user
concerned (nobody) is also /bin/sh (ash). When the user /bin/sh exits
(and thereby login and its parent sh), replimenu receives EIO when it
tries to read from the terminal.
The updated patch adds a config option to explicitely enable 64 bit
arithmetic.
Also it removes the arith prototype from libbb.h as it is not used
outside of ash.
Bastian
this patch has been slightly modified by Erik for cleanliness.
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
