PLFS coreutils checks (was Re: Updated buildscripts (v2.2.8))

Erik-Jan ej.lfs at
Tue Apr 22 15:45:14 PDT 2003

Ryan.Oliver at wrote:
> why not use
> for name in $names; do
>   retname=`su 'id -un' $name
>   test "$name" = "$retname" && { non_root_username=$name; break; }
> done

shouldn't this be:
   retname=`su -c 'id -un' $name`

> at the least its a valid check if the shell is actually a shell, and double
> checks that the user reports itself correctly.

This works nicely, but still gives trouble when the first user with a
valid shell has /bin/bash, because it then tries to read /root/.bashrc
and it doesn't have permission to do so. It passes as a valid shell
though, but when the rm-test is done, the extra permission-error output
screws up the test.

I can think of three solutions: 
1) unsetting BASH_ENV before the su in both the valid-shell and the
rm-test. It is just plain ugly, and who knows what kind of ENV-issues
will emerge when user other shells than bash.
2) using --shell=/bin/sh in both the valid-shell and the rm-test. It
works, most systems will have a /bin/sh, but it bypasses the whole
find-a-valid-shell-test. Most likely it will use bin (in ch5) or nobody
(in ch6) and that just doesn't feel good.
3) sending the bash-error in the valid-shell test to /dev/null like
    retname=`su -c 'id -un' $name 2>/dev/null`
   and doing the rm-test with --shell=/bin/sh, because then you know for
sure how the shell behaves.

> Of course wont work on solaris unless you use /usr/xpg4/bin/id.
> The coreutils guys would have to sort that one out ;-) (shouldn't be too
> hard)
I don't know much about solaris, but the su and id-commands are all in
the coreutils, and the newly built commands are being used in the tests
(try echo `su --version` or echo `su -c 'id --version' $name` inside the
loop, it should give coreutils5.0) so maybe it just goes ok.
> Whaddya guys think? (Mind you I'll have to test it when I get home)
I vote 3. :))

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list