locale testing failures on Tru64

[Andrew Black <ab...@roguewave.com>]

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

Re: locale testing failures on Tru64

[Martin Sebor <se...@roguewave.com>]

Andrew Black wrote:
> Greetings all.
> 
> One more follow up on this issue.
> 
> Attached is a patch that aims to fix this issue by altering the 
> generated locale testing wrapper scripts to set BIN_SH to xpg4 (not xgp4 
> as I erroneously noted in the previous message) for the run_utils script.

Thanks, but I'm afraid I don't like this patch. The makefile
shouldn't need to know that the script it invokes uses getopts.

Here's what I committed instead:
http://svn.apache.org/viewvc?view=rev&rev=487746

Martin

Re: locale testing failures on Tru64

[Andrew Black <ab...@roguewave.com>]

Greetings all.

One more follow up on this issue.

Attached is a patch that aims to fix this issue by altering the 
generated locale testing wrapper scripts to set BIN_SH to xpg4 (not xgp4 
as I erroneously noted in the previous message) for the run_utils script.

--Andrew Black

Changelog:
	* GNUmakefile.bin (SHENV): Define on Compaq Tru64, for use ...
	($(RUNTARGET)): ... Here.  Forces usage of posix compliant Bourne shell.

Re: locale testing failures on Tru64

[Andrew Black <ab...@roguewave.com>]

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