Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <457DC620.60103@roguewave.com>
Date: Mon, 11 Dec 2006 13:57:04 -0700
From: Andrew Black <ablack@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.0.8) Gecko/20061029 SeaMonkey/1.0.6
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: locale testing failures on Tru64
References: <4579E500.7080508@roguewave.com>
In-Reply-To: <4579E500.7080508@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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