On Thu, 27 Jul 2006 06:22:28 +0200 Roland Mainz wrote:
> 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).
ok, shtests will accept name=value args, e.g., LC_ALL=en_US, before
the *.sh args
> ... 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") ?
the latter
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
