He,
there is a bug in HUSH's handling of "if" / "elif" commands:
$ if true
> then
> echo 1
> elif
> true
> then
> echo 2
> elif
> true
> then
> echo 3
> else
> echo 4
> fi
1
2
3
$
The same bug exists in all versions of HUSH from BB v0.60.x up to and
including v1.00-pre9. The attached patch fixes this:
$ if true
> then
> echo 1
> elif
> true
> then
> echo 2
> elif
> true
> then
> echo 3
> else
> echo 4
> fi
1
$
Best regards,
Wolfgang Denk
Just upgraded from 0.6 to 1.00-pre8
Dot command handling handled args correctly (same as bash) in 0.60,
but failed in 1.00:
I fixed this by reverting the dotcmd function back to previous 0.60
instantiation,
please consider using the older version.
Thanks
Peter
It looks like latest uClibc defines ARCH_HAS_MMU, but a few busybox files
test UCLIBC_HAS_MMU, resulting in vfork() getting called instead of
fork(), etc.
Patch below. Only tested for lash.
Cheers,
-Jamie
Hi.
Last changes (rev 1.12) to recursive_actions() by Christian Grigis
have problem.
Test for demonstrate:
$ mkdir aaa bbb ccc
$ su
# chown root bbb
# chmod 700 bbb
# exit
$ busybox chmod 777 -R .
./bbb: Permision denied
But "./ccc" mode not changed. Previous variant works fine,
errors skiped and continued recursion.
--w
vodz
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:
