busybox testsuite on non-linux

[Denys Vlasenko]

On Monday 09 December 2013 14:51, Michael Tokarev wrote:
> Here are a few tests from the testsuite which fails on debian-hurd and
> debian-kfreebsd.

>  pidof this does not print its own pid on hurd or freebsd
>   testing "pidof this" "pidof pidof.tests | grep -o -w $$" "$$\n" "" ""
>   most likely the process is named 'sh pidof.tests', not pidof.tests
> 
> This test fails on both kfreebsd and hurd systems - it does not print
> its own pid, `pidof pidof.tests' prints nothig.

I don't know how thse systems expose process names / argv / executable names.
Do they have "comm" field concept?

For shell scripts, only process name - meaning "comm" field -
allows to identify shell script.
argv[0] and /proc/PID/exe lead to /bin/sh.


>  kfreebsd: group on files is inherited from parent dir. cpio tests fail.
>  FAIL: cpio extracts zero-sized hardlinks
>  --- expected
>  +++ actual
>  @@ -1,4 +1,4 @@
>   1 blocks
>   0
>  --rw-r--r-- 2 2952 1009 0 x
>  --rw-r--r-- 2 2952 1009 0 y
>  +-rw-r--r-- 2 2952 112 0 x
>  +-rw-r--r-- 2 2952 112 0 y
> 
> Mabe remove (using sed, in $FILTER_LS) the group column for testing?
> Note the same may happen on linux too, depending on the filesystem in
> use and even filesystem mount options (-o grpid or -o bsdgroups for a
> few linux filesystems).

You mean, gid of hardlinks? IIRC cpio should restore gid of regular files,
no?

Can you confirm this works?

optional FEATURE_LS_SORTFILES FEATURE_LS_TIMESTAMPS
testing "cpio extracts zero-sized hardlinks" \
"$ECHO -ne '$hexdump' | bzcat | cpio -i 2>&1; echo \$?;
ls -ln cpio.testdir | $FILTER_LS | cut -d' ' -f 1-3,5-" \
                                 ^^^^^^^^^^^^^^^^^^^^^^ add this
"\
1 blocks
0
-rw-r--r-- 2 $user $group 0 x
-rw-r--r-- 2 $user $group 0 y
" "" ""
SKIP=


>  du tests fail on kfreebsd filesystems:
>  du-k-works
>  16+64Kb files in a dir, `du -k .' is expected
>  to be one of 80, 84 or 88, actual is 82.
>  du-l-works - same issue,
>  result expected to be 144, 148, 152 or 156, actual is 146
> 
> I'm not sure why these sizes are multiple of 4Kb.  As you can see,
> on a bsd system the directory size is different.  Maybe any number
> between, say, 80 and 88 should be ok?

I prefer to add only numbers which were actually seen.
Fixed in git, thanks!