[patch] testsuite/testing.sh: removes obvious bashisms
Denys Vlasenko
vda.linux at googlemail.com
Fri May 2 09:40:01 UTC 2008
On Thursday 01 May 2008 18:11, Cristian Ionescu-Idbohrn wrote:
> I'm not sure I found all of them. Didn't test function 'mkchroot', but I
> can't see how my modifications would make it fail.
>
> I tested using bash, dash and ash as shells.
- FAILCOUNT=$[$FAILCOUNT+1]
+ FAILCOUNT=$(($FAILCOUNT + 1))
Ok
- [ "${i:0:1}" == "/" ] || i=$(which $i)
+ first_char=${i#?}
+ first_char=${first_char%$first_char}
+ [ "$first_char" = / ] || i=$(which $i)
Just use i=$(which $i) always.
> You will notice this:
>
> testing()
> {
> + local ECHO='echo -e'
> +
> + [ -z "$($ECHO)" ] || ECHO='echo'
> +
>
> '-e' is non-posix and dash has that builtin. That is, if the standard
> shell is dash (ubuntu and derivatives, and RSN debian):
>
> # echo -e
>
> will output:
>
> -e
>
> and the tests will go wrong and all that...
>
> Maybe some 'echo' replacement like:
>
> ECHO='echo -e'
> [ -z "$($ECHO)" ] || ECHO='echo'
>
> in testsuite/runtest (and then propagated to all scripts in and below the
> testsuite directory) sould be a better way to do it. Thoughts?
>
> 'echo -n' may also cause problems.
>
> I read here:
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
>
> ,----
> | A string to be written to standard output. If the first operand is -n, or
> | if any of the operands contain a backslash ( '\' ) character, the results
> | are implementation-defined.
> |
> | [XSI] [Option Start] On XSI-conformant systems, if the first operand is
> | -n, it shall be treated as a string, not an option.
> `----
>
> 'printf' instead of 'echo -e[n]' may be a safer way do do it, but...
>
> I noticed that even if I replaced 'echo -e[n]' with printf, I still
> run into problems :( For example testsuite/bunzip2.tests:
>
> echo -ne "\x02\x00\x6e\xd7\xac\xfd\x06\x00\x00\x00"
>
> No joy just replacing 'echo -ne' with 'printf', as dash builtin 'printf'
> does not support:
>
> \xHH byte with hexadecimal value HH (1 to 2 digits)
>
> as printf (GNU coreutils) 6.10. bash builtin printf (and even echo), on
> the other hand, seems to support that and more. But posix-printf should
> support octal sequences, so this:
>
> printf "\002\000\156\327\254\375\006\000\000\000"
>
> will work better (see 2nd attachment).
Scary mess. Either declare than we absolutely require echo -ne to work.
Making it work without echo -ne will hurt readability too much.
Or have "echo-n", "echo-ne" and "echo-e" helper programs written in C. 8]
Thus bunzip2.tests.patch is NAKed. Sorry.
In the end, I applied this patch:
diff -d -urpN busybox.2/testsuite/testing.sh busybox.3/testsuite/testing.sh
--- busybox.2/testsuite/testing.sh 2008-04-27 22:36:56.000000000 +0200
+++ busybox.3/testsuite/testing.sh 2008-05-02 11:34:30.000000000 +0200
@@ -79,7 +79,7 @@ testing()
cmp expected actual >/dev/null 2>/dev/null
if [ $? -ne 0 ]
then
- FAILCOUNT=$[$FAILCOUNT+1]
+ FAILCOUNT=$(($FAILCOUNT + 1))
echo "FAIL: $NAME"
[ -n "$VERBOSE" ] && diff -u expected actual
else
@@ -107,7 +107,8 @@ mkchroot()
shift
for i in "$@"
do
- [ "${i:0:1}" == "/" ] || i=$(which $i)
+ #bashism: [ "${i:0:1}" == "/" ] || i=$(which $i)
+ i=$(which $i) # no-op for /bin/prog
[ -f "$dest/$i" ] && continue
if [ -e "$i" ]
then
--
vda
More information about the busybox
mailing list