Fix parsing of all tag-value pairs (in modules.conf in particular).
Without this fix, code chokes badly on lines where either value or
both tag+value are missing, like bare
alias
line, or alias w/o the value like
alias some-module
(syntactically incorrect, but no need for coredumps either).
Initialize all fields of struct dep_t.
Without that, e.g. `busybox modprobe -v char-major-10-144' *sometimes*
fails this way (strace):
write(1, "insmod nvram `\213\f\10\n", 21) = 21
Note the garbage after module name which is taken from the m_options field,
which is not initialized in the alias reading/parsing part.
(Shell properly complains to this command, telling it can't find the
closing backtick)
Hello everyone,
Busybox's insmod fails to locate a module when that module is the only one
existing in the /lib/modules directory (with a unique name).
Example:
# find /lib/modules/ -type f
/lib/modules/kernel/drivers/char/bios.o
# insmod bios
insmod: bios.o: no module by that name found
# touch /lib/modules/dummy
# find /lib/modules/ -type f
/lib/modules/kernel/drivers/char/bios.o
/lib/modules/dummy
# insmod bios
Using /lib/modules/kernel/drivers/char/bios.o
As long as there is another file in the /lib/modules directory, insmod
finds it OK.
I tracked the problem down to 'check_module_name_match()' in insmod.c:
It returns TRUE when a match is found, and FALSE otherwise. In the case
where there is only one module in the /lib/modules directory (or more that
one module, but all with the same name), 'recursive_action()' will return
TRUE and we end up on line 4196 in 'insmod.c' which returns an error.
[The reason it works with more than one module with different
names is that in this case there will always be one not matching,
'recursive_action()' will return FALSE and we end up in line 4189.]
Now, from the implementation of 'recursive_action()' and from other
usages of it (tar.c, etc.), it seems to me that FALSE should be returned
to indicate that we want to stop the recursion, so TRUE and FALSE should
be inverted in 'check_module_name_match()'.
At the same time, 'recursive_action()' continues to recurse even after
the recursive call has returned FALSE; again in my understanding and
other usages of it, we can safely stop recursing at this point.
Here is my patch against 1.00-pre8:
'testsuite' dir. Fix a bunch of broken tests. Fix the testsuite
'runtest' script so it actually reports all failures and provides
meaningful feedback.
-Erik
Hi to all,
I discovered a little bug in hdparm.c
(really two little bugs...I've made...sigh! Mea culpa).
Some vars were modified only locally and this could lead to wrong
results to be displayed with the -I switch and maybe with others.
Attached is a patch that fix it ( +88b).
Also attached is second patch that reduces the size a little bit:
text data bss dec hex filename
27984 624 900 29508 7344 hdparm.o (without bug-fix)
28072 624 900 29596 739c hdparm.o (with bug-fix)
28141 624 900 29665 73e1 hdparm.o (original)
but maybe this one can wait as we are in a feature freeze.
Ciao,
Tito
sed -i "/^boo/a fred" ipsec.conf
Which works in gnu sed. (And is _supposed_ to strip all the whitespace before
"fred".)
It also broke:
sed -i -e "/^boo/a \\" -e " fred" ipsec.conf
I.E. there can legally be spaces between the a and the backslash at the end of
the line.
And strangely enough, gnu sed accepts the following syntax as well:
sed -i "/^boo/a \\ fred" ipsec.conf
Which is a way of having the significant whitespace at the start of the line,
all on one line. (But notice that the whitespace BEFORE the slash is still
stripped, as is the slash itself. And notice that the naieve placement of
"\n" there doesn't work, it puts an n at the start of the appended line. The
double slashing is for shell escapes because you could escape the quote, you
see. It's turned into a single backslash. But \n there is _not_ turned into
a newline by the shell. So there.)
This makes all three syntaxes work in my tests. I should probably start
writing better documentation at some point. I posted my current sedtests.py
file to the list, which needs a lot more tests added as well...
The sed command in busybox 1.0.0-pre8 loses leading whitespace
in 'a' command ('i' and 'c' commands are also affected). A
patch to fix this is attached at the end of this message.
The following is a transcript that reproduces the problem. The
first run uses busybox 1.0.0-pre3 as "/bin/sed" command, which
gets the expected result. Later in the test, /bin/sed symlink
is changed to point at busybox 1.0.0-pre8 and the test script is
run again, which shows the failure.
=== reproduction recipe ===
* Part 1. Use busybox 1.0.0-pre3 as sed; this works.
root# cd /tmp
root# cat 1.sh
#!/bin/sh
cd /tmp
rm -f ipsec.conf ipsec.conf+
cat >ipsec.conf <<\EOF
version 2.0
config setup
klipsdebug=none
plutodebug=none
plutostderrlog=/dev/null
conn %default
keyingtries=1
...
EOF
sed -e '/^config setup/a\
nat_traversal=yes' ipsec.conf >ipsec.conf+
mv -f ipsec.conf+ ipsec.conf
root# sh -x 1.sh
+ cd /tmp
+ rm -f ipsec.conf ipsec.conf+
+ cat
+ sed -e /^config setup/a\
nat_traversal=yes ipsec.conf
+ mv -f ipsec.conf+ ipsec.conf
root# cat ipsec.conf
version 2.0
config setup
nat_traversal=yes
klipsdebug=none
plutodebug=none
plutostderrlog=/dev/null
conn %default
keyingtries=1
...
root# sed --version
sed: invalid option -- -
BusyBox v1.00-pre3 (2004.02.26-18:47+0000) multi-call binary
Usage: sed [-nef] pattern [files...]
* Part 2. Continuing from the above, use busybox 1.0.0-pre8
as sed; this fails.
root# ln -s busybox-pre8 /bin/sed-8
root# mv /bin/sed-8 /bin/sed
root# sed --version
This is not GNU sed version 4.0
root# sed --
BusyBox v1.00-pre8 (2004.03.30-02:44+0000) multi-call binary
Usage: sed [-nef] pattern [files...]
root# sh -x 1.sh
+ cd /tmp
+ rm -f ipsec.conf ipsec.conf+
+ cat
+ sed -e /^config setup/a\
nat_traversal=yes ipsec.conf
+ mv -f ipsec.conf+ ipsec.conf
root# cat ipsec.conf
version 2.0
config setup
nat_traversal=yes
klipsdebug=none
plutodebug=none
plutostderrlog=/dev/null
conn %default
keyingtries=1
...
root#
=== reproduction recipe ends here ===
This problem was introduced in 1.0.0-pre4. The problem is that
the command argument parsing code strips leading whitespaces too
aggressively. When running the above example, the piece of code
in question gets "\n\tnat_traversal=yes" as its argument in
cmdstr variable (shown part in the following patch). What it
needs to do at this point is to strip the first newline and
nothing else, but it instead strips all the leading whitespaces
at the beginning of the string, thus losing the tab character.
The following patch fixes this.
