Glenn Fowler wrote:
> On Thu, 27 Jul 2006 04:25:31 +0200 Roland Mainz wrote:
> > While doing some tests with the ksh93 (ksh93r+_20060724 on Solaris
> > 11/Nevada B37) test suite I tried to add /usr/xpg4/bin to ${PATH} in the
> > test setup which then caused "path.sh" to fail like this:
> > -- snip --
> > % (for i in ../src/cmd/ksh93/tests/path.sh ; do echo "## $i " ; env -
> > SHELL=$PWD/../arch/sol11.i386/bin/ksh HOME=$HOME
> > PATH=/usr/xpg4/bin:/usr/bin:/bin LANG=C LC_ALL=C
> > $PWD/../arch/sol11.i386/bin/ksh "$i" ; done)
> > ## ../src/cmd/ksh93/tests/path.sh
> > ../src/cmd/ksh93/tests/path.sh[145]: mkdir: not found [No such file or
> > directory]
> > ../src/cmd/ksh93/tests/path.sh[146]: bin/tst: cannot create [No such
> > file or directory]
> > ../src/cmd/ksh93/tests/path.sh[147]: chmod: not found [No such file or
> > directory]
> >         path.sh[149]: (PATH=$PWD/bin foo) does not find $PWD/bin/foo
> > -- snip --
> 
> > Removing /usr/xpg4/bin from ${PATH} makes the test succeed again as
> > normal.
> 
> > Is this a bug in the test suite or something else ?
>
> 
> the tests are expected to be run via the shtests harness:
> 
>         $SHELL ../src/cmd/ksh93/tests/shtests ../src/cmd/ksh93/tests/path.sh
> 
> shtests tames and normalizes the environment for all tests

Ok... I didn't knew anything about "shtests". A quick look at it shows
it has one drawback - it unsets LC_ALL and LANG, effectively killing the
option to test other locales than the system default one (in the
ksh93-integration prototype we now re-run the test suite for the
following locales: C, en_US, en_US.UTF-8, he_IL.UTF-8, hi_IN.UTF-8,
ja_JP.PCK, ja_JP.UTF-8, ja_JP.eucJP, ko_KR.EUC, th_TH.TIS620, zh_CN.EUC,
zh_CN.GBK, zh_CN.GB18030, zh_CN.UTF-8,   zh_HK.BIG5HK, zh_TW.BIG5,
zh_TW.EUC and zh_TW.UTF-8 - which should cover as much encodings as
possible and all markets (e.g. china, japan, korea, india, europe, US
etc.) which are important for Sun).
Note that the default system locale may not be "C" and I guess that
setting it to "C" explcitly may a better option in this case (and it
would be nice to add a command line option to override this that we can
test non-C locales, too).

... but AFAIK this doesn't answer my original question: Is this a
problem that POSIX/XPG4-compilant executables are now in ${PATH} or is
this simply the result of a ${PATH} with more than the expected set of
elements (e.g. "/bin:/usr/bin" or "/bin:/usr/bin:/usr/ucb") ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Reply via email to