[patch] testsuite/testing.sh: removes obvious bashisms

[Denys Vlasenko]

On Friday 02 May 2008 15:36, Cristian Ionescu-Idbohrn wrote:
> On Fri, 2 May 2008, Denys Vlasenko wrote:
> 
> > On Friday 02 May 2008 13:52, Cristian Ionescu-Idbohrn wrote:
> > >
> > > Obviously you don't like printf :)
> >
> > I don't have any problems with it. I just know that new-style scripts
> > can break if we switch to it, because their strings can contain "%".
> >
> > Therefore it cannot be used.
> 
> Do we have control over those strings?
> Could you give an RL example?

testsuite/pidof.tests
#!/bin/sh

# pidof tests.
# Copyright 2005 by Bernhard Fischer
# Licensed under GPL v2, see file LICENSE for details.

# AUDIT:

. testing.sh

# testing "test name" "options" "expected result" "file input" "stdin"

testing "pidof (exit with error)" \
        "pidof veryunlikelyoccuringbinaryname ; echo \$?" "1\n" "" ""
testing "pidof (exit with success)" "pidof pidof > /dev/null; echo \$?" \
        "0\n" "" ""
# We can get away with this because it says #!/bin/sh up top.

testing "pidof this" "pidof pidof.tests | grep -o -w $$" "$$\n" "" ""

optional FEATURE_PIDOF_SINGLE
testing "pidof -s" "pidof -s init" "1\n" "" ""

optional FEATURE_PIDOF_OMIT
# This test fails now because process name matching logic has changed,
# but new logic is not "wrong" either... see find_pid_by_name.c comments
#testing "pidof -o %PPID" "pidof -o %PPID pidof.tests | grep -o -w $$" "" "" ""
testing "pidof -o %PPID NOP" "pidof -o %PPID -s init" "1\n" "" ""
testing "pidof -o init" "pidof -o 1 init | grep -o -w 1" "" "" ""

exit $FAILCOUNT





testsuite/uuencode.tests
#!/bin/sh

# unit test for uuencode to test functionality.
# Copyright 2006 by Erik Hovland <erik at hovland.org>
# Licensed under GPL v2, see file LICENSE for details.

# AUDIT: Unit tests for uuencode

. testing.sh

# testing "test name" "options" "expected result" "file input" "stdin"
#   file input will be file called "input"
#   test can create a file "actual" instead of writing to stdout

# Test setup of standard input
saved_umask=$(umask)
umask 0
testing "uuencode sets standard input mode correctly" \
        "uuencode foo </dev/null | head -n 1 | grep -q 666 && echo yes" "yes\n" "" ""
umask $saved_umask

testing "uuencode correct encoding" "uuencode bb_uuenc_test.out" \
"begin 644 bb_uuenc_test.out\nM5&AE(&9A<W0 at 9W)E>2!F;W@@:G5M<&5D(&]V97(@=&AE(&QA>GD at 8G)O=VX@\n%9&]G+ at H\`\n\`\nend\n" \
        "" "The fast grey fox jumped over the lazy brown dog.\n"
testing "uuencode correct base64 encoding" "uuencode -m bb_uuenc_test.out" \
"begin-base64 644 bb_uuenc_test.out\nVGhlIGZhc3QgZ3JleSBmb3gganVtcGVkIG92ZXIgdGhlIGxhenkgYnJvd24g\nZG9nLgo=\n====\n" \
        "" "The fast grey fox jumped over the lazy brown dog.\n"
exit $FAILCOUNT


> 
> > Therefore neither echo -ne nor printf is ok.
> 
> Hmm...  Still, they can be used in many cases, as long as we control the
> strings.
> 
> > I propose using helper binary.
> 
> Well, I can't say I'm happy about it, but it might be needed.  Still, I'd
> like to see some RL examples that show there is no other way.
> 
> 
> Cheers,
>