bug#47382: runtest doesn't work with Solaris 10 /bin/sh

[Rainer Orth]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> I had expected that some system out there might do this when I resisted
> pressure to more aggressively use newer shell constructs in the 
> "dejagnu" multipurpose launcher script.
>
> The previous maintainer had changed this because shellcheck complains about
> the old `backticks` form.  I have chosen rework the script to return to ``
> instead of $() and `expr ...` instead of $((...)) before rc2.
>
> As I am unable to test on Solaris, these reports are particularly helpful.

As it happens, you could get access: there are gcc210 (Solaris 10) and
gcc211 (Solaris 11.3) in the GCC compile farm.  Not saying you should,
of course, it's just an option.

> A patch has been pushed to Savannah on the "dejagnu-1.6.3" branch and will
> be included in release candidate 2.  While I would prefer if you could
> confirm that the patch fixes this bug prior to releasing rc2, I will
> understand if you do not have Git on your Solaris machine.

While I don't (any longer), that wouldn't matter: I can easily check out
the sources on a newer system and used it from there via NFS.

> This issue should be fixed in commit
> e3b14d8555c5cabad03b9ccaa6aa1976ed590201 on the dejagnu-1.6.3 branch.  
> After the 1.6.3 release, bugfixes on that branch will be forward-ported to
> master.

Unfortunately, I got to testing this only now (with rc2), and the
results are not encouraging, unfortunately:

* first, I get

  runtest: !: not found

  another construct not supported by the original bourne shell.  While
  looking at this, I noticed that this is in

if ! command -v "$expectbin" > /dev/null ; then

  However, /bin/sh doesn't have an internal command either.  As it
  happens, an /usr/bin/command exists for POSIX.1 compatibility, which
  just calls /usr/bin/ksh.  This may be ok in this particular case, but
  if it works in general from /bin/sh scripts remains a question.

* There's also

Native configuration is /vol/src/gnu/dejagnu/dejagnu-1.6.3-rc2/config.guess: syn
tax error at line 35: `me=$' unexpected

  another POSIX shell construct, and less easily avoided because this
  comes from upstream.

  I'd already noticed another instance of the problem after I'd sent the
  original PR: while e.g. autoconf-generated configure and related in
  gcc are very careful to invoke config.guess only prefixed with $SHELL,
  runtest.exp exec's it directly, again falling into the trap of POSIX
  shell constructs (also $(), maybe more).

* Next, I had

/vol/src/gnu/dejagnu/dejagnu-1.6.3-rc2/dejagnu: Variants=gawk awk tcl exp bash 
sh: is not an identifier

  from

readonly Variants="gawk awk tcl exp bash sh"

  yet one more.

Seeing all this suggests to me that my suggestion of substituting

#!@SHELL@

into the DejaGnu shell scripts at build time (and making sure other
invocations of shell scripts are prefixed with a POSIX shell, too) is a
safer approach and avoids cripling the scripts with bourne shell constructs
that cannot even be tested reliably.  After all, users of Solaris 10 (or
any other system without a POSIX /bin/sh) are well accustomed to setting
CONFIG_SHELL to either /bin/ksh or /bin/bash to avoid issues with the
ancient bourne shell.

I've tried that by hacking #!/bin/ksh into the dejagnu and runtest
scripts in the source dir as well as prefixing the exec ... config.guess
in runtest.exp with /bin/ksh either.  This way, all runtest tests PASS.

However, there are more errors still:

                === launcher Summary ===

# of expected passes            5
# of unexpected failures        45
# of unsupported tests          2

                === report-card Summary ===

# of unresolved testcases       2

Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-rc2/testsuite/report-card.all/onetest
.exp ...
spawn /bin/sh -c cd /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc2/testsuite/report-card
.all/onetest && exec /vol/src/gnu/dejagnu/dejagnu-1.6.3-rc2/dejagnu report-card^
M
expr: syntax error
ERROR: could not resolve command dejagnu-report-card

There are obviously more hardcoded uses of /bin/sh here and elsewhere,
but I haven't looked for those yet.