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

[Jacob Bachmeyer]

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