GNU bug report logs - #47382
runtest doesn't work with Solaris 10 /bin/sh

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47382 in the body.
You can then email your comments to 47382 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: bug-dejagnu <at> gnu.org
Subject: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 25 Mar 2021 11:33:02 +0100

When trying DejaGnu 1.6.3 rc1 on Solaris 10, it failed immediately with:

runtest: syntax error at line 43: `execpath=$' unexpected

The script hardcodes #!/bin/sh, but the Solaris 10 /bin/sh is
effectively the old Bourne Shell and doesn't support $().

There are several options, I believe:

* Substitute a shell that does (like /bin/ksh in the Solaris 10 case).

* Rework the script to avoid the construct.

* Give up in horror and declare Solaris 10 unsupported, preferably with
  a decent error message at configure time.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Message #8 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 25 Mar 2021 23:46:47 -0500

Rainer Orth wrote:
> When trying DejaGnu 1.6.3 rc1 on Solaris 10, it failed immediately with:
>
> runtest: syntax error at line 43: `execpath=$' unexpected
>
> The script hardcodes #!/bin/sh, but the Solaris 10 /bin/sh is
> effectively the old Bourne Shell and doesn't support $().
>
> There are several options, I believe:
>
> * Substitute a shell that does (like /bin/ksh in the Solaris 10 case).
>
> * Rework the script to avoid the construct.
>
> * Give up in horror and declare Solaris 10 unsupported, preferably with
>   a decent error message at configure time.

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.  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.

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.

I plan to look at the other two bugs you reported tomorrow.


-- Jacob

Message #13 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Wed, 31 Mar 2021 14:23:35 +0200

Jacob Bachmeyer <jcb62281 <at> 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.

Message #16 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 01 Apr 2021 18:58:55 -0500

Rainer Orth wrote:
> Jacob Bachmeyer <jcb62281 <at> 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.
>   

I will look into it.

> [...]
>> 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.
>   

The system providing an external command(1) command should not be a 
problem, even if its implementation using the /usr/bin/ksh builtin is 
somewhat amusing.

This also suggests that we are "almost there" in terms of making runtest 
run with Solaris 10 /bin/sh; the very next command in the script is to 
exec Expect, which gets us away from the shell and its limitations.  
(Give up?  One step away from success?  No!)

The Autoconf shell guidelines specifically say that using ! like that in 
"if" is not portable.  This is fixed in commit 
c35660505e4ec0a79a1ca0e5ea88d6e78caa1778 which applies this patch to 
runtest:

8<----
diff --git a/runtest b/runtest
index b2e0a4c..807a6ae 100755
--- a/runtest
+++ b/runtest
@@ -152,7 +152,7 @@ if [ -z "$runpath" ] ; then
    exit 1
fi

-if ! command -v "$expectbin" > /dev/null ; then
+if command -v "$expectbin" > /dev/null ; then :; else
    echo "ERROR: unable to find expect in the PATH"
    exit 1
fi
8<----

> * 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.
>   

This is a bigger problem.  I do not want to maintain forked config.guess 
and/or config.sub scripts.

> * Next, I had
>
> /vol/src/gnu/dejagnu/dejagnu-1.6.3-rc2/dejagnu: Variants=gawk awk tcl exp bash sh: is not an identifier

This seems to be a minor issue, fixed in commit 
40c351f14a4342d63dcca6a9c72ae81486a1f375 which applies this patch to 
dejagnu:  (but see below)

8<----
diff --git a/dejagnu b/dejagnu
index 695c4e5..44c8962 100755
--- a/dejagnu
+++ b/dejagnu
@@ -53,7 +53,8 @@
# ##end

# list of extensions supported for commands in priority order
-readonly Variants="gawk awk tcl exp bash sh"
+Variants='gawk awk tcl exp bash sh'
+readonly Variants

## Recognize options

8<----


>   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).
>
> [...]
>
> 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.

So far, none of these changes have been close to crippling the scripts.

Using "#!@SHELL@" is not an option because I want DejaGnu to be able to 
run from the source tree, at least on reasonably modern Free systems.  
The ability to run DejaGnu from a Git checkout should help make up for 
the loss of support for the old Cygnus tree layout.  However, 
"#!/bin/sh" on the first line is similarly unique, so...

>  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.
>   

... I am considering arranging for configure to patch the shell scripts 
exactly like that.  At minimum, the config.* scripts that get installed 
will need to be patched to use the configure SHELL in their #! lines 
even if I do manage to get the launcher scripts to run under Solaris 10 
/bin/sh.

Since the runtest launcher script has previously run under ancient 
Bourne shells, I consider it failing to run while any systems still use 
such ancient shells to be a regression that needs to be fixed.  The 
dejagnu launcher script is newer and more complex, so it may actually 
need a newer shell, but (as you have reported) there still seems to be a 
problem with Solaris 10 /bin/ksh.

> However, there are more errors still:
>
>                 === launcher Summary ===
>
> # of expected passes		5
> # of unexpected failures	45
> # of unsupported tests		2
>   

Can you post the launcher.log file?  The dejagnu script is fairly 
simple, and I suspect that I may be able to deduce the causes of those 
failures, especially if they are like the "report-card" failure that 
follows.

> 		=== 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.

That hardcoded use of /bin/sh only changes directory and execs 
$LAUNCHER, which should run with /bin/ksh if you have patched its #! line.

The "dejagnu" script is run, but fails to locate the report-card 
subcommand.  I would be interested in the output of "/bin/ksh -x 
./dejagnu report-card" in the source directory, assuming that "-x" 
produces an execution trace from ksh as it does from bash (... and 
likewise for Solaris 10 /bin/sh after applying the patch above to change 
the use of the readonly command).  There are two likely candidates I see 
for this error:  one is an `expr :` match to detect a leading "-" and 
the other is a possibility that `expr $# \> 0` in a while loop test is 
somehow being executed as `expr \> 0` under some condition.  Both of 
these hypotheses imply unexpected behavior if not outright bugs in 
Solaris 10.

There is a possibility here that dejagnu may be tickling a bug in 
Solaris 10 /bin/ksh and may work with /bin/sh, or may not work with 
either of them.


-- Jacob

Message #19 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 08 Apr 2021 22:39:57 -0500

Rainer Orth wrote:
> * 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.
>   

As of commit 2ca7d52dfa1726aadd1363e399d9b41429332017, which will be in 
release candidate 3, configure now contains experimental logic to 
address this issue by patching the interpreter line in config.guess and 
config.sub when SHELL is not /bin/sh.

>   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).
>   

The "exec" used in this case is Tcl's exec(n), which simply invokes the 
installed copy of config.guess (via the system) with the interpreter 
indicated in the file.  The patch now applied by configure should 
correct this issue.

> However, there are more errors still:
>
> [...]
>
> 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.

If this issue remains in rc3, I repeat my request for execution traces 
under both /bin/sh and /bin/ksh for the rc3 version of the dejagnu 
launcher script.  Please attach the output of "/bin/ksh -x ./dejagnu 
report-card" and "/bin/sh -x ./dejagnu report-card" with both run in the 
DejaGnu source directory when you get the chance if there are still issues.

I have delayed extending the "shell swap" logic in configure to the 
dejagnu launcher script because I am currently uncertain whether it will 
help solve any problems.


-- Jacob

Message #22 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: Jacob Bachmeyer <jcb62281 <at> gmail.com>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Wed, 14 Apr 2021 15:40:56 +0200

Hi Jacob,

> Rainer Orth wrote:
>> * 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.
>>   
>
> As of commit 2ca7d52dfa1726aadd1363e399d9b41429332017, which will be in
> release candidate 3, configure now contains experimental logic to 
> address this issue by patching the interpreter line in config.guess and
> config.sub when SHELL is not /bin/sh.

I'll restrict my reply to this issue for the moment because that logic
caused quite a number of issues:

* On Solaris 10 with CONFIG_SHELL=/bin/ksh, configure substituted
  /bin/ksh into the #! line of both config.guess and config.sub.
  Unfortunately, this has many issues:

* The modified files weren't made executable, leading to lots of
  failures from the likes of

Native configuration is couldn't execute "/vol/src/gnu/dejagnu/dejagnu-1.6.3-rc3/config.guess": permission denied

* Even if I manually make the scripts executable, this isn't a proper
  solution: runtest.exp looks for config.guess in quite a number of
  places, and many projects rely on being able to drop newer
  config.{guess,sub} versions into their source trees to support targets
  that may not even have existed at the time the version of DejaGnu used
  was released.  So using the CONFIG_SHELL should be in the exec line in
  runtest.exp.

* Besides, modifying files in the source tree is wrong for several
  reasons:

** Read-only source trees need to be supported.

** If you share the same source tree between several targets, which is
   quite common, you might end up with a shell in #! on a second target
   that may not even exist there.

  While this could be avoided by making the substitutions to a copy in
  the build tree, the issue vanishes if runtest.exp uses the proper
  shell in the exec.

Message #25 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: Jacob Bachmeyer <jcb62281 <at> gmail.com>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Wed, 14 Apr 2021 16:12:28 +0200

Hi Jacob,

>>   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).
>>   
>
> The "exec" used in this case is Tcl's exec(n), which simply invokes the
> installed copy of config.guess (via the system) with the interpreter 
> indicated in the file.  The patch now applied by configure should correct
> this issue.

true, but according to my manual testing

exec $SHELL $config_guess

with SHELL initialized from CONFIG_SHELL, works just as well and avoids
having to substitute the scripts imported from upstream.

>> However, there are more errors still:
>>
>> [...]
>>
>> 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.
>
> If this issue remains in rc3, I repeat my request for execution traces
> under both /bin/sh and /bin/ksh for the rc3 version of the dejagnu 
> launcher script.  Please attach the output of "/bin/ksh -x ./dejagnu
> report-card" and "/bin/sh -x ./dejagnu report-card" with both run in the 
> DejaGnu source directory when you get the chance if there are still issues.

It does, and happens with both /bin/sh and /bin/ksh: here's an excerpt
from running

env EXPECT=true TCLSH=true /bin/ksh -x /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc3/10-fresh/testsuite/launcher.all/command/bin/dejagnu foo -v -v

+ test -f /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc3/10-fresh/testsuite/launcher.all
/command/share/dejagnu/commands/dejagnu.sh
+ expr foo : -
+ 1> /dev/null
expr: syntax error

There are several more instances, all for

expr foo : -

Solaris /bin/expr just errors out with

expr: syntax error

This applies not only to Solaris 10 /bin/expr, but also to the Solaris
11.4 one as well as /usr/xpg6/bin/expr there.  It seems this is no
wonder:

expr foo : -

is not in XPG7/POSIX.1 and the autoconf manual explicitly states that
this is an unportable non-POSIX extension.

Message #28 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Wed, 14 Apr 2021 22:59:07 -0500

Rainer Orth wrote:
> [...] that logic caused quite a number of issues:
>
> * On Solaris 10 with CONFIG_SHELL=/bin/ksh, configure substituted
>   /bin/ksh into the #! line of both config.guess and config.sub.
>   

It worked!  :-)

>   Unfortunately, this has many issues:
>
> * The modified files weren't made executable, leading to lots of
>   failures from the likes of
>
> Native configuration is couldn't execute "/vol/src/gnu/dejagnu/dejagnu-1.6.3-rc3/config.guess": permission denied
>   

Oops... :-)  I said that logic was experimental.  :-D  I will need to 
rethink this again, since you mention other problems.

> * Even if I manually make the scripts executable, this isn't a proper
>   solution: runtest.exp looks for config.guess in quite a number of
>   places, and many projects rely on being able to drop newer
>   config.{guess,sub} versions into their source trees to support targets
>   that may not even have existed at the time the version of DejaGnu used
>   was released.

While runtest.exp *looks* in several places, it will almost always 
*find* config.guess in either $libdir (typical when running from DejaGnu 
source tree), $libdir/libexec (typical when installed), or $execpath 
(DejaGnu source tree, DEJAGNULIBS overriding $libdir).  I could replace 
the rest of those with $execpath/libexec to pick up the installed 
config.guess near runtest.exp even if DEJAGNULIBS is used and remove the 
others, as they would never be used.  They are already very unlikely to 
ever be used.

>   So using the CONFIG_SHELL should be in the exec line in
>   runtest.exp.
>   

This leads us right back to the same problem:

> * Besides, modifying files in the source tree is wrong for several
>   reasons:
>
> ** Read-only source trees need to be supported.
>   

(Aside:  Automake does not necessarily support read-only source trees.  
For example, building in an object tree can result in an Info file in 
the source tree being rebuilt.  I remember seeing this happen while 
building other GNU releases in the past.)

> ** If you share the same source tree between several targets, which is
>    quite common, you might end up with a shell in #! on a second target
>    that may not even exist there.
>
>   While this could be avoided by making the substitutions to a copy in
>   the build tree, the issue vanishes if runtest.exp uses the proper
>   shell in the exec.

For runtest.exp to use the proper shell, it must somehow *get* that 
information from configure.  So, instead of patching the #! line in 
config.guess, we would need to patch runtest.exp.  While, again, we 
could key the patch off of a unique line (here the only line containing 
"exec $config_guess" sans quotes) or arrange for a default value of 
"/bin/sh" if SHELL is still "@SHELL@" as it will be in the source 
directory prior to running configure, there are a few possibilities here:

* Fix the executable permission problem, but leave the NFS shared source 
tree issue to twist in the wind.  (bad)

* Patch the "exec $config_guess" in runtest.exp, also leaving the NFS 
shared source tree issue to twist in the wind. (also bad)

* Copy config.guess to the build tree and patch it there for 
installation.  This should be workable but will break running DejaGnu 
from a Git checkout on Solaris 10.  I note that this feature is 
currently broken on Solaris 10 anyway due to /bin/sh not being able to 
run config.guess.  This may also cause a few errors with the DejaGnu 
testsuite, as the DejaGnu tests would be run with a shell error in the 
place of a build triplet.  (Wait... why are we not picking up the build 
system triplet from site.exp if configure has been used?  That would 
avoid the need to run config.guess in the source directory, at least 
when building for installation...)

If host_triplet and/or build_triplet are set in the init files, such as 
site.exp, DejaGnu does not bother running config.guess at all.  This 
will cover the case of testing DejaGnu itself, and patching the 
installed copy of config.guess can cover the general case.  I should be 
able to use EXTRA_DEJAGNU_SITE_CONFIG to handle this for DejaGnu itself, 
and I will need to consider offering a patch to Automake to add that 
generally, since transferring build/host/target information through 
site.exp would probably be useful for most packages.


-- Jacob

Message #31 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Wed, 14 Apr 2021 23:00:17 -0500

Rainer Orth wrote:
> [...] here's an excerpt from running
>
> env EXPECT=true TCLSH=true /bin/ksh -x /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc3/10-fresh/testsuite/launcher.all/command/bin/dejagnu foo -v -v
>
> + test -f /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc3/10-fresh/testsuite/launcher.all
> /command/share/dejagnu/commands/dejagnu.sh
> + expr foo : -
> + 1> /dev/null
> expr: syntax error
>   

Thank you!  That identifies the problem.  As of commit 
c95e2e9b567a1c3ca22b2de4fdcdfe4b99ba2a03, the dejagnu launcher script 
now uses the shell "case" builtin for that pattern match instead of 
using expr:

8<----
diff --git a/dejagnu b/dejagnu
index 44c8962..9f6ae4b 100755
--- a/dejagnu
+++ b/dejagnu
@@ -152,9 +152,7 @@ command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
while expr $# \> 0 > /dev/null
do
    if test -z "${command}" ; then
-       if expr "$1" : - > /dev/null ; then
-           break
-       fi
+       case $1 in -*) break;; esac
       command="$1"
       shift
    fi
@@ -167,9 +165,7 @@ do
           break 2
       fi
    done
-    if expr "$1" : - > /dev/null ; then
-       break
-    fi
+    case $1 in -*) break;; esac
    if test -n "$1" ; then
       command="${command}-$1"
       shift
8<----


> It seems this is no wonder:
>
> expr foo : -
>
> is not in XPG7/POSIX.1 and the autoconf manual explicitly states that
> this is an unportable non-POSIX extension.

Can you cite exactly where in the Autoconf manual that is mentioned?  
The closest that I can find is a recommendation to use `expr X"word" : 
'Xregex'` to handle cases where "word" starts with a dash; here Solaris 
10 is rejecting a case where "word" is "foo".



-- Jacob

Message #34 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: Jacob Bachmeyer <jcb62281 <at> gmail.com>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 13:56:51 +0200

Jacob Bachmeyer <jcb62281 <at> gmail.com> writes:

>>   Unfortunately, this has many issues:
>>
>> * The modified files weren't made executable, leading to lots of
>>   failures from the likes of
>>
>> Native configuration is couldn't execute
>> "/vol/src/gnu/dejagnu/dejagnu-1.6.3-rc3/config.guess": permission denied
>>   
>
> Oops... :-)  I said that logic was experimental.  :-D  I will need to
> rethink this again, since you mention other problems.

I still believe that using the tried-and-try AC_SUBST (like automake
does in t/java-compile-run-flat.sh and t/java-compile-run-nested.sh with
#!@SHELL@) would solve most issues nicely:

* not writing to $srcdir

* supporting both in-tree and VPATH builds

* most likely the permission issue

This has been successfully used for years if not decades and is most
certainly well tested in situations we may not even have thought about :-)

>> * Even if I manually make the scripts executable, this isn't a proper
>>   solution: runtest.exp looks for config.guess in quite a number of
>>   places, and many projects rely on being able to drop newer
>>   config.{guess,sub} versions into their source trees to support targets
>>   that may not even have existed at the time the version of DejaGnu used
>>   was released.
>
> While runtest.exp *looks* in several places, it will almost always *find*
> config.guess in either $libdir (typical when running from DejaGnu source
> tree), $libdir/libexec (typical when installed), or $execpath (DejaGnu
> source tree, DEJAGNULIBS overriding $libdir).  I could replace the rest of
> those with $execpath/libexec to pick up the installed config.guess near
> runtest.exp even if DEJAGNULIBS is used and remove the others, as they
> would never be used.  They are already very unlikely to ever be used.

Maybe (I haven't dug into this in detail) the fact that e.g. the gcc
testsuite uses the in-gcc-tree config.guess is because site.exp is
generated at make check time, emitting *_triplet into per-testsuite
versions of site.exp.

>>   So using the CONFIG_SHELL should be in the exec line in
>>   runtest.exp.
>
> This leads us right back to the same problem:
>
>> * Besides, modifying files in the source tree is wrong for several
>>   reasons:
>>
>> ** Read-only source trees need to be supported.
>>   
>
> (Aside:  Automake does not necessarily support read-only source trees.  For
> example, building in an object tree can result in an Info file in the
> source tree being rebuilt.  I remember seeing this happen while building
> other GNU releases in the past.)

Creating new files in the source tree (and failing; gcc has gone to some
lenghts to avoid this) is one thing; modifying the unpacked sources in
place is quite another.

When you use AC_SUBST as I suggested, that usually takes an
in-source-tree runtest.exp.in (or some such; you can specify the exact
file names using AC_CONFIG_FILES) and write the result to the build
directory.  You just need to make sure that you use the generated file
during make check and make install, which is easy if the filenames differ.

>> ** If you share the same source tree between several targets, which is
>>    quite common, you might end up with a shell in #! on a second target
>>    that may not even exist there.
>>
>>   While this could be avoided by making the substitutions to a copy in
>>   the build tree, the issue vanishes if runtest.exp uses the proper
>>   shell in the exec.
>
> For runtest.exp to use the proper shell, it must somehow *get* that
> information from configure.  So, instead of patching the #! line in 

As I said, the established convention is to use $CONFIG_SHELL if set and
fall back to /bin/sh if not.

> config.guess, we would need to patch runtest.exp.  While, again, we could
> key the patch off of a unique line (here the only line containing "exec
> $config_guess" sans quotes) or arrange for a default value of "/bin/sh" if
> SHELL is still "@SHELL@" as it will be in the source directory prior to
> running configure, there are a few possibilities here:

No need to key off anything when using AC_SUBST: you pass the files to
be substituted via AC_CONFIG_FILES, then at configure time all uses of
the substituted variables (@SHELL@ in this case) are substituted and the
resulting files places in the build dir.  Alternatively, you could
create a global config file at configure time that contains something
like

set dg_shell = @SHELL@

and always source that.  If this is more reliable than just fixing
runtest.exp(.in) itself is your decision; I for one doubt it.

> * Fix the executable permission problem, but leave the NFS shared source
>   tree issue to twist in the wind.  (bad)
>
> * Patch the "exec $config_guess" in runtest.exp, also leaving the NFS
>   shared source tree issue to twist in the wind. (also bad)
>
> * Copy config.guess to the build tree and patch it there for installation.
>  This should be workable but will break running DejaGnu from a Git checkout
> on Solaris 10.  I note that this feature is currently broken on Solaris 10
> anyway due to /bin/sh not being able to run config.guess.  This may also
> cause a few errors with the DejaGnu testsuite, as the DejaGnu tests would
> be run with a shell error in the place of a build triplet.  (Wait... why
> are we not picking up the build system triplet from site.exp if configure
> has been used?  That would avoid the need to run config.guess in the source
> directory, at least when building for installation...)

Seems like an incredibly complicated dance to me just to avoid chaning
the above

exec $config_guess

to

exec $dg_shell $config_guess

and be done with it: no need to modify imported files and working with
unmodified out-of-tree copies of config.guess at that.

> If host_triplet and/or build_triplet are set in the init files, such as
> site.exp, DejaGnu does not bother running config.guess at all.  This 
> will cover the case of testing DejaGnu itself, and patching the installed
> copy of config.guess can cover the general case.  I should be able to use
> EXTRA_DEJAGNU_SITE_CONFIG to handle this for DejaGnu itself, and I will
> need to consider offering a patch to Automake to add that generally, since
> transferring build/host/target information through site.exp would probably
> be useful for most packages.

Please keep in mind that this needs to continue working with existing
versions of automake.  As an example, gcc currently uses automake 1.15.1
and autoconf 2.69 and upgrading either or both is far from trivial,
certainly not going to be undertaken just to be able a newer version of
DejaGnu.

Message #37 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: Jacob Bachmeyer <jcb62281 <at> gmail.com>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 14:14:18 +0200

Jacob Bachmeyer <jcb62281 <at> gmail.com> writes:

> Rainer Orth wrote:
>> [...] here's an excerpt from running
>>
>> env EXPECT=true TCLSH=true /bin/ksh -x
>> /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc3/10-fresh/testsuite/launcher.all/command/bin/dejagnu
>> foo -v -v
>>
>> + test -f
>> /vol/gcc/obj/dejagnu/dejagnu-1.6.3-rc3/10-fresh/testsuite/launcher.all
>> /command/share/dejagnu/commands/dejagnu.sh
>> + expr foo : -
>> + 1> /dev/null
>> expr: syntax error
>>   
>
> Thank you!  That identifies the problem.  As of commit 
> c95e2e9b567a1c3ca22b2de4fdcdfe4b99ba2a03, the dejagnu launcher script 
> now uses the shell "case" builtin for that pattern match instead of 
> using expr:

Fine, thanks.

>> It seems this is no wonder:
>>
>> expr foo : -
>>
>> is not in XPG7/POSIX.1 and the autoconf manual explicitly states that
>> this is an unportable non-POSIX extension.
>
> Can you cite exactly where in the Autoconf manual that is mentioned?  
> The closest that I can find is a recommendation to use `expr X"word" : 
> 'Xregex'` to handle cases where "word" starts with a dash; here Solaris 
> 10 is rejecting a case where "word" is "foo".

Upon re-checking, I seem to have misread the relevant section, sorry.
The fact remains, however, that XPG7 doesn't list that variant on

https://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

which suggests (together with the behaviour of /usr/xpg6/bin/expr which
has been certified for XPG conformance AFAIK) that this usage is an
extension.

Message #40 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: Jacob Bachmeyer <jcb62281 <at> gmail.com>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 16:23:31 +0200

Jacob Bachmeyer <jcb62281 <at> gmail.com> writes:

>> However, there are more errors still:
>>
>>                 === launcher Summary ===
>>
>> # of expected passes		5
>> # of unexpected failures	45
>> # of unsupported tests		2
>>   
>
> Can you post the launcher.log file?  The dejagnu script is fairly 
> simple, and I suspect that I may be able to deduce the causes of those 
> failures, especially if they are like the "report-card" failure that 
> follows.

After the fix for the expr foo : - issue, I've made some progress in
identifying what's still going wrong:

I now see

Running "env EXPECT=true TCLSH=true /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/bin/dejagnu foo -v -v" ...
Verbose level is 2
Running launcher from /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/bin
Probing directory /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/share/dejagnu/commands
Looking for commands in /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/share/dejagnu/commands
ERROR: could not resolve command dejagnu-foo
child process exited abnormally
FAIL: dejagnu foo as Tcl

Comparing sh -x output between Solaris 10 and 11, I found that the
difference starts in dejagnu at this point:

# Remove any leading autoconf platform prefix and the "dejagnu" prefix.
command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`

* S10 or 11 with /usr/bin/sed:

  command=dejagnu

* S11.3 with /usr/gnu/bin/sed:

  command=

The issue is the Solaris sed vs. GNU sed difference: /usr/bin/sed
behaves identically between Solaris 10 and 11, however GNU sed isn't
bundled with Solaris 10.

Solaris sed doesn't support ? in REs (cf. regexp(7)).  The Autoconf
manual documents

Portable @command{sed} regular expressions should use @samp{\} only to escape
characters in the string @samp{$()*.0123456789[\^n@{@}}.  For example,
alternation, @samp{\|}, is common but Posix does not require its
support, so it should be avoided in portable scripts.  Solaris
@command{sed} does not support alternation; e.g., @samp{sed '/a\|b/d'}
deletes only lines that contain the literal string @samp{a|b}.
Similarly, @samp{\+} and @samp{\?} should be avoided.

One can use \{0,1\} instead, but I cannot tell for certain how portable
that is:

diff --git a/dejagnu b/dejagnu
--- a/dejagnu
+++ b/dejagnu
@@ -147,7 +147,7 @@ if $want_version ; then
 fi
 
 # Remove any leading autoconf platform prefix and the "dejagnu" prefix.
-command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
+command=`basename "$0" | sed -e 's/^.*-\{0,1\}dejagnu-\{0,1\}//'`
 
 while expr $# \> 0 > /dev/null
 do

With that fixed I ran into:

Found subcommand foo with variants:  tcl sh
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
Selected variant tcl

grep -q isn't portable, too, also documented in the Autoconf manual:

Some of the options required by Posix are not portable in practice.
Don't use @samp{grep -q} to suppress output, because traditional @command{grep}
implementations (e.g., Solaris) do not support @option{-q}.

Using I/O redirection instead got me way further:

diff --git a/dejagnu b/dejagnu
--- a/dejagnu
+++ b/dejagnu
@@ -235,7 +235,7 @@ if $have_gawk ; then
 fi
 # is "awk" actually GNU Awk?
 if $have_awk ; then
-    if "$awkbin" --version | sed 1q | grep -qi 'GNU Awk' ; then
+    if "$awkbin" --version | sed 1q | grep -i 'GNU Awk' > /dev/null; then
        have_gawk_as_awk=true
     else
        have_gawk_as_awk=false
@@ -406,8 +406,8 @@ if $want_help ; then
        echo ERROR: file "'$help_file'" is not readable
        exit 2
     fi
-    if grep -q '#help' "$help_file" \
-       && grep -q '#end' "$help_file"; then : ; else
+    if grep '#help' "$help_file" > /dev/null \
+       && grep '#end' "$help_file" > /dev/null; then : ; else
        echo ERROR: file "'$help_file'" does not contain a help message
        exit 2
     fi

Now I'm down to

Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/command.exp ...
FAIL: dejagnu --help works
FAIL: dejagnu foo --help works if shell variant selected

This only occurs when running runtest --tool launcher manually, but
works with make check.

Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/help.exp ...
ERROR: The 'man' command in Solaris does not work in the source tree.
Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/interp.exp ...
FAIL: have no Awk
FAIL: have no GNU Awk
FAIL: have no Tcl
FAIL: have no Expect

Running "env AWK=bogus GAWK=bogus /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/dejagnu --DGTimpl awk" ...
child process exited abnormally
FAIL: have no Awk

Those FAILs happen because interp.exp expects exitcode 1 while we get
255 instead.  The autoconf manual documents this, too:

Don't expect @command{false} to exit with status 1: in native
Solaris @file{/bin/false} exits with status 255.

>> 		=== 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.
>
> That hardcoded use of /bin/sh only changes directory and execs 
> $LAUNCHER, which should run with /bin/ksh if you have patched its #! line.
>
> The "dejagnu" script is run, but fails to locate the report-card 
> subcommand.  I would be interested in the output of "/bin/ksh -x 
> ./dejagnu report-card" in the source directory, assuming that "-x" 
> produces an execution trace from ksh as it does from bash (... and 
> likewise for Solaris 10 /bin/sh after applying the patch above to change 
> the use of the readonly command).  There are two likely candidates I see 
> for this error:  one is an `expr :` match to detect a leading "-" and 
> the other is a possibility that `expr $# \> 0` in a while loop test is 
> somehow being executed as `expr \> 0` under some condition.  Both of 
> these hypotheses imply unexpected behavior if not outright bugs in 
> Solaris 10.
>
> There is a possibility here that dejagnu may be tickling a bug in 
> Solaris 10 /bin/ksh and may work with /bin/sh, or may not work with 
> either of them.

When I retried this now, the report-card results are good:

		=== report-card Summary ===

# of expected passes		245

Message #43 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 23:46:29 -0500

Rainer Orth wrote:
> Jacob Bachmeyer <jcb62281 <at> gmail.com> writes:
>   
>> [...]
>>     
> [...]
>   
> Maybe (I haven't dug into this in detail) the fact that e.g. the gcc
> testsuite uses the in-gcc-tree config.guess is because site.exp is
> generated at make check time, emitting *_triplet into per-testsuite
> versions of site.exp.
>   

If the reply I have seen on the DejaGnu list so far is correct, that is 
*exactly* what GCC already does, what I intend to do with 
EXTRA_DEJAGNU_SITE_CONFIG for 1.6.3, and what I intend to try to push to 
upstream Automake:  carry the *_triplet values from configure into 
site.exp.  DejaGnu does not run GCC's copy of config.guess, but is given 
the result that configure previously obtained by running it or the value 
that the user provided to configure.

However, DejaGnu will /still/ need to install (and possibly use) 
config.guess because initialization files are optional in DejaGnu, so we 
cannot depend on *_triplet being set in site.exp because site.exp is not 
actually required to exist.  >-<

>> (Aside:  Automake does not necessarily support read-only source trees.  For
>> example, building in an object tree can result in an Info file in the
>> source tree being rebuilt.  I remember seeing this happen while building
>> other GNU releases in the past.)
>>     
>
> Creating new files in the source tree (and failing; gcc has gone to some
> lenghts to avoid this) is one thing; modifying the unpacked sources in
> place is quite another.
>   

I have observed Automake-derived Makefiles rebuilding shipped Info files 
in the past (or complaining that makeinfo is not installed).  I never 
bothered to look into why this happened, but I have seen it happen.

> When you use AC_SUBST as I suggested, that usually takes an
> in-source-tree runtest.exp.in (or some such; you can specify the exact
> file names using AC_CONFIG_FILES) and write the result to the build
> directory.  You just need to make sure that you use the generated file
> during make check and make install, which is easy if the filenames differ.
>   

To compensate for dropping support for the old Cygnus tree layout, we 
now support running DejaGnu directly from a Git checkout; this is 
extremely convenient for development and precludes using AC_SUBST to 
produce runtest.exp from a runtest.exp.in.  (There are also many 
long-standing assumptions in the code about relative paths from 
runtest.exp to other parts of DejaGnu, so runtest.exp needs to be in the 
source tree, or the DejaGnu testsuite will have problems that I really 
do not want to try to fix on a release branch.)

>>> ** If you share the same source tree between several targets, which is
>>>    quite common, you might end up with a shell in #! on a second target
>>>    that may not even exist there.
>>>
>>>   While this could be avoided by making the substitutions to a copy in
>>>   the build tree, the issue vanishes if runtest.exp uses the proper
>>>   shell in the exec.
>>>       
>> For runtest.exp to use the proper shell, it must somehow *get* that
>> information from configure.  So, instead of patching the #! line in 
>>     
>
> As I said, the established convention is to use $CONFIG_SHELL if set and
> fall back to /bin/sh if not.
>   

If I understand correctly, CONFIG_SHELL may no longer be in the 
environment when "make check" is run, although its value will have been 
propagated to the SHELL make variable, but I do not think that Automake 
exports that back to the environment.

>> * Fix the executable permission problem, but leave the NFS shared source
>>   tree issue to twist in the wind.  (bad)
>>
>> * Patch the "exec $config_guess" in runtest.exp, also leaving the NFS
>>   shared source tree issue to twist in the wind. (also bad)
>>
>> * Copy config.guess to the build tree and patch it there for installation.
>>  This should be workable but will break running DejaGnu from a Git checkout
>> on Solaris 10.  I note that this feature is currently broken on Solaris 10
>> anyway due to /bin/sh not being able to run config.guess.  This may also
>> cause a few errors with the DejaGnu testsuite, as the DejaGnu tests would
>> be run with a shell error in the place of a build triplet.  (Wait... why
>> are we not picking up the build system triplet from site.exp if configure
>> has been used?  That would avoid the need to run config.guess in the source
>> directory, at least when building for installation...)
>>     
>
> Seems like an incredibly complicated dance to me

This will be a complicated dance no matter what I do, but I might have a 
simple answer below.

> just to avoid chaning
> the above
>
> exec $config_guess
>
> to
>
> exec $dg_shell $config_guess
>
> and be done with it: no need to modify imported files and working with
> unmodified out-of-tree copies of config.guess at that.
>   

There are a few problems here.  The largest is that the NFS shared 
source tree problem comes back in a different form after installation:  
DejaGnu is installed in an architecture-independent tree 
(/usr/share/dejagnu) so the installed copy cannot depend on results from 
configure that could be valid on some machines in a testing lab and 
wrong on others.  This is the same problem that we get with patching the 
#! line in config.guess.

I was considering getting a proper shell to use from the global 
initialization file, since that could be configured by the testing lab 
operators to check the hostname to determine which shell to use, but 
that would have to wait for the 1.7 release and will not work either:  
the global site.exp is allowed to assume that the *_triplet variables 
have already been set.

This leads to another possibility:  could we simply require that 
CONFIG_SHELL be set in the environment if /bin/sh cannot run 
config.guess?  The main runtest.exp could easily do:

   if { [info exists ::env(CONFIG_SHELL)] } {
       catch { exec $::env(CONFIG_SHELL) $config_guess } ...
   } else {
       catch { exec $config_guess } ...
   }


The only problem I see here would be if it is common to do 
"CONFIG_SHELL=/bin/ksh /path/to/src/configure ..." instead of simply 
"export CONFIG_SHELL=/bin/ksh" in a .login or similar file.  Two 
advantages here are that this preserves the current code path on all 
systems that can use it, and an "elseif" branch to check ::env(SHELL) 
could be easily added as well.  DejaGnu will have to be a bit stricter 
about ensuring that config.guess actually ran and produced usable 
output, to catch the case of CONFIG_SHELL being needed but no longer set 
(or SHELL being tcsh), but this is looking feasible since it does not 
require "customizing" any of the supposedly machine-independent files.

>> If host_triplet and/or build_triplet are set in the init files, such as
>> site.exp, DejaGnu does not bother running config.guess at all.  This 
>> will cover the case of testing DejaGnu itself, and patching the installed
>> copy of config.guess can cover the general case.  I should be able to use
>> EXTRA_DEJAGNU_SITE_CONFIG to handle this for DejaGnu itself, and I will
>> need to consider offering a patch to Automake to add that generally, since
>> transferring build/host/target information through site.exp would probably
>> be useful for most packages.
>>     
>
> Please keep in mind that this needs to continue working with existing
> versions of automake.  As an example, gcc currently uses automake 1.15.1
> and autoconf 2.69 and upgrading either or both is far from trivial,
> certainly not going to be undertaken just to be able a newer version of
> DejaGnu.

This use of EXTRA_DEJAGNU_SITE_CONFIG is for DejaGnu itself and the 
DejaGnu testsuite, to avoid running config.guess when testing DejaGnu 
itself, because user-specified triplets should be carried through.  As 
such, moving that upstream will cause other packages to carry *_triplet 
information through automatically when they move to newer Automake, and 
the EXTRA_DEJAGNU_SITE_CONFIG file added to DejaGnu can be removed when 
DejaGnu *itself* moves to a newer Automake that propagates the *_triplet 
values to site.exp by default.

As one answer to an RFC about this on the DejaGnu mailing list 
mentioned, GCC *already* overrides Automake's rule for site.exp and does 
exactly what I am planning to suggest that upstream Automake should do 
(and a lot more, so they will still need to override Automake's site.exp 
rule).

On the other hand, if we can use an environment variable in runtest.exp, 
all of this becomes moot for 1.6.3 and carrying *_triplet through can 
land in 1.6.4 instead, which I would prefer.


-- Jacob

Message #46 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 23:46:37 -0500

Rainer Orth wrote:
> Jacob Bachmeyer <jcb62281 <at> gmail.com> writes:
>
>   
>>> However, there are more errors still:
>>>
>>>                 === launcher Summary ===
>>>
>>> # of expected passes		5
>>> # of unexpected failures	45
>>> # of unsupported tests		2
>>>   
>>>       
>> Can you post the launcher.log file?  The dejagnu script is fairly 
>> simple, and I suspect that I may be able to deduce the causes of those 
>> failures, especially if they are like the "report-card" failure that 
>> follows.
>>     
>
> After the fix for the expr foo : - issue, I've made some progress in
> identifying what's still going wrong:
>   

Many thanks for your efforts.

> I now see
>
> Running "env EXPECT=true TCLSH=true /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/bin/dejagnu foo -v -v" ...
> Verbose level is 2
> Running launcher from /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/bin
> Probing directory /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/share/dejagnu/commands
> Looking for commands in /vol/gcc/obj/dejagnu/dejagnu-1.6.3-branch/10/testsuite/launcher.all/command/share/dejagnu/commands
> ERROR: could not resolve command dejagnu-foo
> child process exited abnormally
> FAIL: dejagnu foo as Tcl
>
> Comparing sh -x output between Solaris 10 and 11, I found that the
> difference starts in dejagnu at this point:
>
> # Remove any leading autoconf platform prefix and the "dejagnu" prefix.
> command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
>
> * S10 or 11 with /usr/bin/sed:
>
>   command=dejagnu
>
> * S11.3 with /usr/gnu/bin/sed:
>
>   command=
>
> The issue is the Solaris sed vs. GNU sed difference: /usr/bin/sed
> behaves identically between Solaris 10 and 11, however GNU sed isn't
> bundled with Solaris 10.
>
> Solaris sed doesn't support ? in REs (cf. regexp(7)).  The Autoconf
> manual documents
>
> Portable @command{sed} regular expressions should use @samp{\} only to escape
> characters in the string @samp{$()*.0123456789[\^n@{@}}.  For example,
> alternation, @samp{\|}, is common but Posix does not require its
> support, so it should be avoided in portable scripts.  Solaris
> @command{sed} does not support alternation; e.g., @samp{sed '/a\|b/d'}
> deletes only lines that contain the literal string @samp{a|b}.
> Similarly, @samp{\+} and @samp{\?} should be avoided.
>   

At the time I wrote that script, (my first foray into an attempt at 
portable shell) I was using an old Autoconf manual that did not mention 
these issues; I was also trying to avoid using Awk, but DejaGnu 
configure now fails with an error if Awk is not available, which was not 
the case then.

> One can use \{0,1\} instead, but I cannot tell for certain how portable
> that is:
>
> diff --git a/dejagnu b/dejagnu
> --- a/dejagnu
> +++ b/dejagnu
> @@ -147,7 +147,7 @@ if $want_version ; then
>  fi
>  
>  # Remove any leading autoconf platform prefix and the "dejagnu" prefix.
> -command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
> +command=`basename "$0" | sed -e 's/^.*-\{0,1\}dejagnu-\{0,1\}//'`
>  
>  while expr $# \> 0 > /dev/null
>  do
>   

The current Autoconf manual also mentions that basename is not portable; 
I will find a solution, probably using Awk.

> With that fixed I ran into:
>
> Found subcommand foo with variants:  tcl sh
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> Selected variant tcl
>
> grep -q isn't portable, too, also documented in the Autoconf manual:
>
> Some of the options required by Posix are not portable in practice.
> Don't use @samp{grep -q} to suppress output, because traditional @command{grep}
> implementations (e.g., Solaris) do not support @option{-q}.
>   

Another improvement not in the older copy I used when writing that script.

> Using I/O redirection instead got me way further:
>
> diff --git a/dejagnu b/dejagnu
> --- a/dejagnu
> +++ b/dejagnu
> @@ -235,7 +235,7 @@ if $have_gawk ; then
>  fi
>  # is "awk" actually GNU Awk?
>  if $have_awk ; then
> -    if "$awkbin" --version | sed 1q | grep -qi 'GNU Awk' ; then
> +    if "$awkbin" --version | sed 1q | grep -i 'GNU Awk' > /dev/null; then
>         have_gawk_as_awk=true
>      else
>         have_gawk_as_awk=false
> @@ -406,8 +406,8 @@ if $want_help ; then
>         echo ERROR: file "'$help_file'" is not readable
>         exit 2
>      fi
> -    if grep -q '#help' "$help_file" \
> -       && grep -q '#end' "$help_file"; then : ; else
> +    if grep '#help' "$help_file" > /dev/null \
> +       && grep '#end' "$help_file" > /dev/null; then : ; else
>         echo ERROR: file "'$help_file'" does not contain a help message
>         exit 2
>      fi
>   

The help logic will probably get rewritten to use Awk, and the test for 
GNU Awk is another simple string match.  I think I can improve these a 
bit...

> Now I'm down to
>
> Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/command.exp ...
> FAIL: dejagnu --help works
> FAIL: dejagnu foo --help works if shell variant selected
>
> This only occurs when running runtest --tool launcher manually, but
> works with make check.
>
> Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/help.exp ...
> ERROR: The 'man' command in Solaris does not work in the source tree.
> Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/interp.exp ...
> FAIL: have no Awk
> FAIL: have no GNU Awk
> FAIL: have no Tcl
> FAIL: have no Expect
>
> Running "env AWK=bogus GAWK=bogus /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/dejagnu --DGTimpl awk" ...
> child process exited abnormally
> FAIL: have no Awk
>
> Those FAILs happen because interp.exp expects exitcode 1 while we get
> 255 instead.  The autoconf manual documents this, too:
>
> Don't expect @command{false} to exit with status 1: in native
> Solaris @file{/bin/false} exits with status 255.
>   

That one is in the older Autoconf manual; I just completely overlooked 
it and have fixed it in commit 
9539a1e2ffe8506b92bfcb4363c767e4bc6a0700.  The dejagnu launcher now 
reliably returns code 1 instead of whatever false(1) produces.

>>> 		=== 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.
>>>       
>> That hardcoded use of /bin/sh only changes directory and execs 
>> $LAUNCHER, which should run with /bin/ksh if you have patched its #! line.
>>
>> The "dejagnu" script is run, but fails to locate the report-card 
>> subcommand.  I would be interested in the output of "/bin/ksh -x 
>> ./dejagnu report-card" in the source directory, assuming that "-x" 
>> produces an execution trace from ksh as it does from bash (... and 
>> likewise for Solaris 10 /bin/sh after applying the patch above to change 
>> the use of the readonly command).  There are two likely candidates I see 
>> for this error:  one is an `expr :` match to detect a leading "-" and 
>> the other is a possibility that `expr $# \> 0` in a while loop test is 
>> somehow being executed as `expr \> 0` under some condition.  Both of 
>> these hypotheses imply unexpected behavior if not outright bugs in 
>> Solaris 10.
>>
>> There is a possibility here that dejagnu may be tickling a bug in 
>> Solaris 10 /bin/ksh and may work with /bin/sh, or may not work with 
>> either of them.
>>     
>
> When I retried this now, the report-card results are good:
>
> 		=== report-card Summary ===
>
> # of expected passes		245

These results are very reassuring:  the report-card tool is written in Awk.


-- Jacob

Message #49 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 23:47:20 -0500

Rainer Orth wrote:
> Jacob Bachmeyer <jcb62281 <at> gmail.com> writes:
>   
>> Rainer Orth wrote:
>>     
>>> It seems this is no wonder:
>>>
>>> expr foo : -
>>>
>>> is not in XPG7/POSIX.1 and the autoconf manual explicitly states that
>>> this is an unportable non-POSIX extension.
>>>       
>> Can you cite exactly where in the Autoconf manual that is mentioned?  
>> The closest that I can find is a recommendation to use `expr X"word" : 
>> 'Xregex'` to handle cases where "word" starts with a dash; here Solaris 
>> 10 is rejecting a case where "word" is "foo".
>>     
>
> Upon re-checking, I seem to have misread the relevant section, sorry.
> The fact remains, however, that XPG7 doesn't list that variant on
>
> https://pubs.opengroup.org/onlinepubs/9699919799/toc.htm
>
> which suggests (together with the behaviour of /usr/xpg6/bin/expr which
> has been certified for XPG conformance AFAIK) that this usage is an
> extension.

By my reading of 
<URL:https://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html>, 
"/expr1/ : /expr2/" is a "matching expression", which is explained in 
the next subsection as matching the string /expr1/ against the regular 
expression /expr2/ according to basic regular expression syntax 
explained at 
<URL:https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03>, 
where dash ("-") is not listed as a special character, so that usage of 
expr should be equivalent to matching the glob pattern "-*" as the code 
now does.

Wait... while Solaris seems to be incorrectly rejecting that command, 
cases where it *should* match would be exactly the situation the 
Autoconf manual mentions, with `expr --help : -` as one example where 
expr can incorrectly parse the first expression as an option.

There is still a bug somewhere here, either in Solaris expr or the 
Autoconf manual (or both); I am unsure which, but my reading of the 
specs suggest a bug in Solaris which the Autoconf manual should 
mention.  In any case, the incorrect usage in the dejagnu launcher 
script has now been fixed, thanks again for pointing it out.
I encourage you to report the issue as a documentation bug in Autoconf 
once we get this figured out:  either the Autoconf manual does not 
mention an easy pitfall or the Autoconf manual does not mention a bug on 
Solaris that makes an otherwise portable usage nonportable.


-- Jacob

Message #52 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh (oops,
 forgot patch...)
Date: Fri, 16 Apr 2021 00:01:45 -0500

Rainer Orth wrote:
> Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/help.exp ...
> ERROR: The 'man' command in Solaris does not work in the source tree.
> Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/interp.exp ...
> FAIL: have no Awk
> FAIL: have no GNU Awk
> FAIL: have no Tcl
> FAIL: have no Expect
>
> Running "env AWK=bogus GAWK=bogus /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/dejagnu --DGTimpl awk" ...
> child process exited abnormally
> FAIL: have no Awk
>
> Those FAILs happen because interp.exp expects exitcode 1 while we get
> 255 instead.  The autoconf manual documents this, too:
>
> Don't expect @command{false} to exit with status 1: in native
> Solaris @file{/bin/false} exits with status 255.
>   

Fixed in commit 9539a1e2ffe8506b92bfcb4363c767e4bc6a0700:

8<----
diff --git a/dejagnu b/dejagnu
index 9f6ae4b..ece4e09 100755
--- a/dejagnu
+++ b/dejagnu
@@ -426,13 +426,13 @@ fi
if test -z "$command" ; then
    if test -n "$override_ext" ; then
       case $selected_ext in
-           awk)        $have_awk;      exit $? ;;
-           bash)       $have_bash;     exit $? ;;
-           exp)        $have_expect;   exit $? ;;
-           gawk)       $have_gawk;     exit $? ;;
-           tcl)        $have_tcl;      exit $? ;;
-           sh)         $have_sh;       exit $? ;;
-           *)                          exit  2 ;;
+           awk)    if $have_awk;       then exit 0; else exit 1; fi ;;
+           bash)   if $have_bash;      then exit 0; else exit 1; fi ;;
+           exp)    if $have_expect;    then exit 0; else exit 1; fi ;;
+           gawk)   if $have_gawk;      then exit 0; else exit 1; fi ;;
+           tcl)    if $have_tcl;       then exit 0; else exit 1; fi ;;
+           sh)     if $have_sh;        then exit 0; else exit 1; fi ;;
+           *)      exit 2 ;;
       esac
    else
       echo ERROR: no command given
8<----


That code did look suspiciously clever when I wrote it...


-- Jacob

Message #55 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Fri, 16 Apr 2021 16:50:58 -0500

I have had time to address the rest of these:

Rainer Orth wrote:
> One can use \{0,1\} instead, but I cannot tell for certain how portable
> that is:
>
> diff --git a/dejagnu b/dejagnu
> --- a/dejagnu
> +++ b/dejagnu
> @@ -147,7 +147,7 @@ if $want_version ; then
>  fi
>  
>  # Remove any leading autoconf platform prefix and the "dejagnu" prefix.
> -command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
> +command=`basename "$0" | sed -e 's/^.*-\{0,1\}dejagnu-\{0,1\}//'`
>  
>  while expr $# \> 0 > /dev/null
>  do
>   

Fixed in commit cc4d2e41f5d72be55e2b506f45fa052e1b3d410b; according to 
the latest Autoconf manual, basename is not portable either!

8<----
diff --git a/dejagnu b/dejagnu
index ece4e09..c38dd4d 100755
--- a/dejagnu
+++ b/dejagnu
@@ -147,7 +147,20 @@ if $want_version ; then
fi

# Remove any leading autoconf platform prefix and the "dejagnu" prefix.
-command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
+# command=`basename "$0" | sed -e 's/^.*-\?dejagnu-\?//'`
+# The above simple solution is not portable, so we use Awk:
+command=`echo "$0" | awk 'BEGIN { FS = "/" }
+{   OFS = FS = "-"
+    $0 = $NF
+    for (i = 1; i <= NF; i++) if ($i ~ /dejagnu/) break;
+    for (j = 1; j <= (NF - i); j++) $j = $(j+i);
+    NF = j - 1
+    print }'`
+# Initially splitting on "/", then assigning the last field to the record
+# performs the role of basename.  Splitting on "-" and searching for a
+# field matching /dejagnu/ identifies the other prefixes, and the second
+# loop removes the "dejagnu" prefix and everything before it.  The record
+# is then truncated, printed, and thereby returned to the shell.

while expr $# \> 0 > /dev/null
do
8<----


> With that fixed I ran into:
>
> Found subcommand foo with variants:  tcl sh
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> Selected variant tcl
>
> grep -q isn't portable, too, also documented in the Autoconf manual:
>
> Some of the options required by Posix are not portable in practice.
> Don't use @samp{grep -q} to suppress output, because traditional @command{grep}
> implementations (e.g., Solaris) do not support @option{-q}.
>   

Fixed in commits 84c903914b49e5051f116b7a1512ee6d962d71bc (first) and 
e2fa0bcf54e2bb05106be1ce22a73de4f7381444 (second).  Splitting this also 
allowed for neatly cleaning up the rest of the help display code in the 
second commit.

8<----
diff --git a/dejagnu b/dejagnu
index c38dd4d..57767b1 100755
--- a/dejagnu
+++ b/dejagnu
@@ -248,11 +248,10 @@ if $have_gawk ; then
fi
# is "awk" actually GNU Awk?
if $have_awk ; then
-    if "$awkbin" --version | sed 1q | grep -qi 'GNU Awk' ; then
-       have_gawk_as_awk=true
-    else
-       have_gawk_as_awk=false
-    fi
+    case `"$awkbin" --version 2>&1 | sed 1q` in
+       *'GNU Awk'*)    have_gawk_as_awk=true   ;;
+       *)              have_gawk_as_awk=false  ;;
+    esac
fi
if expr "$verbose" \> 2 > /dev/null ; then
    if $have_awk ; then
8<----


8<----
diff --git a/dejagnu b/dejagnu
index 57767b1..d323a62 100755
--- a/dejagnu
+++ b/dejagnu
@@ -418,21 +418,15 @@ if $want_help ; then
       echo ERROR: file "'$help_file'" is not readable
       exit 2
    fi
-    if grep -q '#help' "$help_file" \
-       && grep -q '#end' "$help_file"; then : ; else
+    if awk '/#help$/ { pfxlen = length($0) - 4 }
+           pfxlen && substr($0, pfxlen) == "#end" { exit 1 }
+          ' "$help_file" ; then
       echo ERROR: file "'$help_file'" does not contain a help message
       exit 2
    fi
-    help_prefix_pat=`grep '#help' "$help_file" \
-       | sed -e 's/#help.*$//' -e '1q' | tr '[:print:][:blank:]' .`
-    if expr "$verbose" \> 1 > /dev/null ; then
-       echo Extracting help from "'$help_file'" with prefix "'$help_prefix_pat'
-    fi
-    sed -n < "$help_file" \
-       -e '1,/#help/d' \
-       -e '/^'"$help_prefix_pat"'#end/q' \
-       -e 's/^'"$help_prefix_pat"'//;p'
-    exit 0
+    exec awk '/#help$/ { pfxlen = length($0) - 4 }
+             pfxlen && substr($0, pfxlen) == "#end" { exit 0 }
+             pfxlen { print substr($0, pfxlen) }' "$help_file"
fi

if test -z "$command" ; then
8<----

> Now I'm down to
>
> Running /vol/src/gnu/dejagnu/dejagnu-1.6.3-branch/local/testsuite/launcher.all/command.exp ...
> FAIL: dejagnu --help works
> FAIL: dejagnu foo --help works if shell variant selected
>
> This only occurs when running runtest --tool launcher manually, but
> works with make check.
>   

Please try the revised help support above; I suspect that there may have 
been other issues.  Working with make check but not directly invoked 
runtest is ... strange.


-- Jacob

Message #58 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Fri, 16 Apr 2021 17:13:12 -0500

Rainer Orth wrote:
> As I said, the established convention is to use $CONFIG_SHELL if set and
> fall back to /bin/sh if not.
>   

As of commit d0f104991b9e6134f04bc674af115bc288c9e137, DejaGnu now 
examines the environment variables CONFIG_SHELL and SHELL (in that 
order) and uses the first one set to invoke config.guess, falling back 
to relying on the #! line in config.guess if neither is set:

8<----
diff --git a/runtest.exp b/runtest.exp
index 3220485..93ae2ab 100644
--- a/runtest.exp
+++ b/runtest.exp
@@ -823,13 +823,52 @@ if {[expr {$build_triplet eq "" && $host_triplet eq ""}]} 
       send_error "ERROR: Couldn't find config.guess program.\n"
       exit 1
    }
-    catch "exec $config_guess" build_triplet
-    switch -- $build_triplet {
-       "No uname command or uname output not recognized" -
-       "Unable to guess system type" {
-           verbose "WARNING: Uname output not recognized"
-           set build_triplet unknown
+    if { [info exists ::env(CONFIG_SHELL)] } {
+       if { [catch {exec $::env(CONFIG_SHELL) $config_guess} build_triplet] } {
+           if { [lindex $::errorCode 0] eq "CHILDSTATUS" } {
+               send_error "ERROR: Running config.guess with\
+                                       CONFIG_SHELL=$::env(CONFIG_SHELL)\
+                                       exited on code\
+                                       [lindex $::errorCode 2].\n"
+           } else {
+               send_error "ERROR: Running config.guess with\
+                                       CONFIG_SHELL=$::env(CONFIG_SHELL)\
+                                       produced error:\n"
+               send_error "        $::errorCode\n"
+           }
+       }
+    } elseif { [info exists ::env(SHELL)] } {
+       if { [catch {exec $::env(SHELL) $config_guess} build_triplet] } {
+           if { [lindex $::errorCode 0] eq "CHILDSTATUS" } {
+               send_error "ERROR: Running config.guess with\
+                                       SHELL=$::env(SHELL)\
+                                       exited on code\
+                                       [lindex $::errorCode 2].\n"
+           } else {
+               send_error "ERROR: Running config.guess with\
+                                       SHELL=$::env(SHELL)\
+                                       produced error:\n"
+               send_error "        $::errorCode\n"
+           }
       }
+    } else {
+       if { [catch {exec $config_guess} build_triplet] } {
+           if { [lindex $::errorCode 0] eq "CHILDSTATUS" } {
+               send_error "ERROR: Running config.guess exited on code\
+                                       [lindex $::errorCode 2].\n"
+           } else {
+               send_error "ERROR: Running config.guess produced error:\n"
+               send_error "        $::errorCode\n"
+           }
+       }
+    }
+    if { ![regexp -- {^[^-]+-[^-]+-[^-]+} $build_triplet] } {
+       send_error "ERROR: Running config.guess produced bogus build triplet:\n"
+       send_error "        $build_triplet\n"
+       send_error "       (Perhaps you need to set CONFIG_SHELL or\
+                               SHELL in your environment\n"
+       send_error "        to the absolute file name of a POSIX shell?)\n"
+       exit 1
    }
    verbose "Assuming build host is $build_triplet"
    if { $host_triplet eq "" } {
8<----


This change also produces an immediate fatal error (before even the 
global init file is read, so very quickly; the user will not have time 
to walk away and be disappointed upon later returning) if running 
config.guess does not produce something that at least vaguely resembles 
a platform triplet and suggests overriding the shell used for running 
config.guess if this occurs.

> Seems like an incredibly complicated dance to me just to avoid chaning
> the above
>
> exec $config_guess
>
> to
>
> exec $dg_shell $config_guess
>
> and be done with it: no need to modify imported files and working with
> unmodified out-of-tree copies of config.guess at that.
>   

It was a little more involved than that because getting a value for 
$dg_shell is non-trivial.  :-)  We cannot rely on any values from 
DejaGnu's configure run once DejaGnu is installed, because DejaGnu is 
installed into the architecture-independent tree.


-- Jacob

Message #63 received at 47382-done <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382-done <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 03 Jun 2021 23:12:18 -0500

This seems to be resolved as of 1.6.3-rc5, with all tests now passing on 
the gcc210 node at the GCC compile farm.

-- Jacob

Message #66 received at 47382-done <at> debbugs.gnu.org (full text, mbox):

From: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
To: Jacob Bachmeyer <jcb62281 <at> gmail.com>
Cc: 47382-done <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Fri, 04 Jun 2021 11:29:05 +0200

Hi Jacob,

> This seems to be resolved as of 1.6.3-rc5, with all tests now passing on
> the gcc210 node at the GCC compile farm.

I've now verified this on Solaris 10, 11.3, and 11.4: all results are
fine.

Thanks a lot for all your work fixing the Solaris issues.

	Rainer

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.