the start of the path. (This should be under the same config option as
the standalone shell, but right now that's buried in the shell menu.)
Also add the ability to specify CONFIG_BUSYBOX_EXEC_PATH with /proc/self/exe
as an overrideable default.
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.
can figure out what header files to include, and override stuff that comes
later. But applets shouldn't include platform.h directly, they should include
busybox.h or libbb.h. Since busybox.h already includes libbb.h, move libbb.h
to the top of busybox.h and platform.h near the top of libbb.h (right after
bbconfig.h, which is something platform.h also needs access to).
While we're at it, move some stuff from busybox.h to libbb.h so we have one
big file to audit/clean up/try to make sense of instead of many.
the following of which (from cat.c) belongs in svn history instead of the
source code:
/* Mar 16, 2003 Manuel Novoa III (mjn3@codepoet.org)
*
* This is a new implementation of 'cat' which aims to be SUSv3 compliant.
*
* Changes from the previous implementation include:
* 1) Multiple '-' args are accepted as required by SUSv3. The previous
* implementation would close stdin and segfault on a subsequent '-'.
* 2) The '-u' options is required by SUSv3. Note that the specified
* behavior for '-u' is done by default, so all we need do is accept
* the option.
*/
This needs a second pass to:
+ add bb_daemon(unsigned char no_chdir, unsigned char no_close, const char*flag)
+ eventually globally export argc and argv, so we don't need to pass it to
bb_daemon().
files still using them. I didn't remove them from e2fsck.c to avoid stomping
pending cleanup patches from Garrett, and I didn't bother to remove them from
fdisk.c because that entire file needs to be rewritten from scratch.
- add ATTRIBUTE_ALWAYS_INLINE, endian handling for DEC UNIX, some more
compiler dependent defines to platform.h
- add conditional bb_setpgrp define to platform.h
- remove superfluous specifying args from "#define fdprintf dprintf"
another... This adds bb_xspawn() support, which does vfork/exec. (I don't
know why using a static instead of a local adds ~40 bytes, but using
the local doesn't work...)
handle packets out of sequence if some data goes through the buffer and
some doesn't, B) it works on systems that can't handle aligned access,
C) we just have one code path to worry about.
While we're at it, sizeof() and RESERVE_CONFIG_BUFFER() really don't combine
well, which is why md5sum has been reading and processing data 4 bytes at a
time. I suspect that the existence of CONFIG_MD5_SIZE_VS_SPEED to do loop
unrolling and such in the algorithm was an attempt to work around that bug.
the side of the tree doesn't _COUNT_, and I will not ship it.
Udhcp was deleted shortly after I posted my philosophy for what should and
shouldn't go into busybox:
http://www.busybox.net/lists/busybox/2006-March/019484.html
I complained about the change t the time. I've complained repeatedly since.
But nobody felt like fixing it. External dependencies are something to be
minimized. I don't care about the ability for packages to build outside
busybox: something is either part of busybox, or it isn't. If I convert any
part of the external udhcp repository to use libbb, I've broken the external
package. Any random cleanups that touch that directory suddenly have to worry
about external dependencies that are NOT OUR PROBLEM. Therefore, that
directory is not and cannot be part of busybox. Wishful thinking isn't going
to change that. I will not ship something I can't maintain.
I'll try to get a new dhcp client and server in before the ship window closes,
but I have a half-dozen other projects pending. I'm sorry this happened, but
I'm not the one who removed it, and I'm not the one who ignored the project
maintainer's repeated complaints about the situation for the next month and a
half.