bash: use setpriv, sed.sed to run ptests

The execscript test in bash fails when run with ptest-runner calling
'su', with the error:
   bash: cannot set terminal process group (16036): Inappropriate ioctl for device
Even with ptest-runner fixed to make a child process use the right
process group, 'su' still results in the warning above. Use 'setpriv'
instead. 'runuser' was considered and works but depends on pam so it's
ruled out.

Now that all bash tests are run as a user, the patch:
   fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
can be removed.  Also to create the account 'bashtest' in the
'run-ptest' script the bash-ptest must depend on 'shadow'. Also,
in 'run-ptest', ensure that the bash ptests are owned by the 'bashtest' user.

Add 'sed' as a dependency for ptests since tests/exp8.sub runs:
    var=$'x\001y\177z'
    declare -p var | sed -n l
and that results in:
    sed.busybox: ""
    sed.sed: declare -- var="x\001y\177z"$
This appears to be a feature that busybox sed has not implemented.

With this series of changes, bash-ptest for qemux86-64 passes
79 of 81 tests. The remaining failures are:

1. run-read:
  # cat tests/read6.sub
  # test read with a timeout of 0 -- input polling
  # sleep with fractional seconds argument is not universal
  echo abcde | { sleep 0.25 2>/dev/null ; read -t 0; }
  echo $?

  read -t 0 < $0
  echo $?

  read -t 0
  echo $? <-- returns 1, when 0 is expected.

I can reproduce this on my workstation but only when using ptest-runner
and initially logging into the console as root. That's a little odd and
seems like I need to continue to improve ptest-runner.

2. run-trap:
  # cat tests/trap3.sub
  PS4='+[$LINENO] '
  trap 'echo trap: $LINENO' ERR

  set -x

  echo 1
  echo 2
  echo 3 | cat | false <--- error
  echo 4

This is a scheduler behaviour difference between the common case
on a workstation and the common case in qemu. The test case does
warn about the completion order not being deterministic so I plan
to ignore it.

>From tests/run-trap:
  UNIX versions number signals and schedule processes differently.
  If output differing only in line numbers is produced, please
  do not consider this a test failure.

Still, it's notable and slightly odd that the common case output
is different.

(From OE-Core rev: 81e3f01867cf114b728ab5a417c29426c9bf8122)

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

0 files changed, 0 insertions, 0 deletions