Greetings all.
A quick follow-up on this issue. The following simplified test case,
when passed the options '-x -a -b foo bar' demonstrates the behavior
problem we're seeing.
#!/bin/sh
echo $*
while getopts "ab:" opt_name; do
echo "Option $opt_name=$OPTARG"
done
A Bourne shell with a functional getopt command will return something
similar to the following, while /bin/sh on Tru64 (by default) produces
only the first line.
-x -a -b foo bar
/tmp/shtest.sh: illegal option -- x
Option ?=
Option a=
Option b=foo
According to http://www.in-ulm.de/~mascheck/bourne/#osf1 , the Bourne
shell on this platform appears to be a SVR2 shell with a number of
backports. (getopts was added in SVR3, and wasn't included in those
backports).
The reason I say 'by default' is because the behavior of /bin/sh changes
if BIN_SH is set to 'xgp4' or 'svr4'. The former value causes an
XCUS5.0/POSIX.2 compliant shell to be launched, while the later causes a
SVR4 compliant shell to be launched. Both shells include support for
the getopts built-in.
It seems to me that the best solution to the behavior observed is to set
BIN_SH to xgp4 prior to invoking the run_locale_utils.sh script, but I
am uncertain as to the best place to do so. One option is to embed the
setting of this variable into the generated locale test scripts
($(RUNTARGET) pattern rule in GNUmakefile.bin). A second option is to
set this variable when running each locale test script (run and %.out
targets in makefile.rules, I think). The third option is to set this
variable outside the infrastructure (in the glue scripts).
Of these options, I view the first and third as more desirable than the
second. The first two either require a new makefile variable or
platform specific logic in the rules. The third doesn't require
makefile changes, but will be a tripping point for users unfamiliar with
this quirk. I consider the first more desirable than the second, as it
would ensure that the variable is always set if it's needed. In
choosing between the shell variants, my understanding is that the shell
scripts are coded to the POSIX spec, and therefore xgp4 would be a more
accurate shell choice.
--Andrew Black
Andrew Black wrote:
Greetings all.
One of the persistent failures observed in automated testing is the
locale tests on Tru64. I have performed a manual build, and it appears
that the cause is a failure in the run_locale_utils.sh script. The
output of running both the sanity_test.sh wrapper script and the
en_US.ANSI_X3.4-1968.sh wrapper script is as follows:
./run_utils: Usage : script -s -b <bindir> ## checking sanity
script -f -i <nlsdir> -l <locale name> ## check functionality
Looking at the script, it seems to me that the version of sh living in
/bin/sh is deficient in it's processing of the getopts command. I do
not have a solution to this problem at this time, but I hope to look
into it next week.
--Andrew Black
