as far as I can tell, are no longer relevant. Modern busybox refuses to
build under libc5 (there's a specific test and #error for that), and
I'm not sure building against 2.1 kernel headers on Alpha was ever relevant.
I'm happy to put any of this back if anybody can point to a real need for it,
but if so we need to specifically document what environment is being
compensated for. (And we should quarrantine the build environment code
into one place, anyway. Maybe "quirks.h" for known compiler and
libc quirks?)
This fixes the warning, and makes the binary smaller out of sheer pique.
(Yes, since Manuel did this one it's nice tight code that took several
attempts to shrink, but I was ticked.)
Add the start of a test for uniq; this is about the first 1/3 of the
tests we need for full susv3 coverage of uniq.
CONFIG_NUMERIC_CONSTANT=
And on reading it back in, it would complain that '' was an invalid value for
that field. I.E. "make allnoconfig && make" worked fine, but
"make allnoconfig && make menuconfig" barfed reading in the config file.
So now I have it write out "0" as the blank value. (It's initialized to the
default value when the menu becomes visible anyway; I checked.) That seems
to work.
./busybox getopt -n one -n two woot
./busybox getopt -o one -o two woot
This entire applet is still an enormous pile of garbage, which I can't clean
up because I really have no idea what it's for. (Both "man getopt" and trying
it out on the command line a bit fail to enlighten me. Reading the code, the
fact half of it seems to be special cases for bash vs tcsh does not fill me
with confidence.)
The configure system's save function edited out sub-menus that wouldn't be
displayed in the current configuration, meaning config.h wouldn't have #udef
entries for those symbols, meaning bb_config.h would have the relevant
ENABLE_ missing instead of defined to 0. This broke the build.
So I fixed it, and then reorganized the applets.c and busybox.c to take
away the warnings this revealed (code that would be optimized out was making
calls to functions that hadn't been prototyped. So I added an #else case
to those #ifdefs to #define the relevant functions to empty macros to
placate the warnings.
I also reorganized the applets.c code to make adding such an #else case less
of a pain (and make the need for prototyping go away by moving the functions
up before they were used, and generally wind up with fewer #ifdefs in
the code by putting all the logic in one place). This resulted in a huge
seeming patch, when most if it just moves code from one place to another
without touching it...
Upside: make allyesconfig and make allnoconfig should both work now.
(I.E. any argv[0] that starts with "busybox" winds up in busybox_main().)
Added testing/busybox.tests which tests the following permutations:
./busybox
./busybox-suffix
./busybox cat
./busybox-suffix cat
./busybox --help
./busybox-suffix --help
./busybox --help cat
./busybox-suffix --help cat
./busybox --help unknown
./busybox-suffix --help unknown
./unknown
Also repair the test suite so ./runtest calls the ".tests" scripts properly.
Note: you can now go "busybox busybox busbox ls -l" and it'll take it. The
new code is pretty generic. I can block that if anybody can come up with a
good reason to...
the result of the ioctl so callers can tell if we have a tty. (0 means
we have a tty, nonzero means the ioctl couldn't find size info and we
fake 80x24. Really we should fake 80x25, but oh well...)
Otherwise if you build busybox without a given applet you get the wrong error
message when you call it via a symlink to that applet.
(You also get the wrong behavior; it tries to use argv[1] as the command
name just like busybox does for _any_ unknown, and although I doubt
"echo rm -rf *" is common usage there's no upside and enough downside to
make me nervous.)
This fixes it.
added to the list, and my assumption that nfsmount() actually called
mount() was incorrect (and I coded it wrong anyway; I hate having to touch
codepaths I can't personally test).
can never be made because useMtab is initialized to 0, and all the other
assignments of that variable assign 0 to it. Any compiler that can perform
simple constant propogation on local variables will optimize away if statements
testing against that variable, thus the call to erase_mtab() will never be
made.
When compiling for arm using gcc 3.3.3 with FEATURE_MTAB_SUPPORT disabled,
the linker complains that it can't find erase_mtab(). The arm optimizer isn't
exactly the brightest member of the family, and apparently needs to be hit over
the head with a hammer to get its' attention...
