On Mon, Jul 26, 2010 at 10:29 PM, Glenn Fowler <[email protected]> wrote:
>
> On Mon, 26 Jul 2010 22:16:08 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= 
> wrote:
>> Glenn, can a caller of shtests still override LC_ALL/LANG?
>
> not as it stands now
>
> the idea is C locale is the default for all test writers
> tests exercising locale-specific features should set the locale in the test 
> script
> because of the default, allowing shtests to override it may invalidate some 
> tests

Erm... I have very strong concerns about this change.
Until now we (=the OpenSolaris ksh93-integration project) assumed that
the "shtests" frontend resets the LANG variable to "C" (we do this
additionally externally and unset all LC_* variables) and that we can
override this with any locale which is a superset of the ASCII
encoding and has the decimal delimiter set to '.' (in OpenSolaris one
of the basic test procedures is to iterate over all locales reported
by $ locale =a # which have the decimal delimiter set to '.' ... this
takes a long time but helps a lot to keep the quality at a very good
level).
This helped a lot in the past digging out problems (either in the
ksh93/AST codebase or in the Solaris i18n code) in other locales, for
example the multibyte locales which often have seperate codepaths from
the single-byte locales.

However... if this gets changed and all modules use "C" by default we
loose the abilty and the tests will cover _much_ less ground and code
than we currently do.

IMO a better solution would be to unset all LC_* variables in
"shtests", set LANG='C', allow the caller  of "shtests" to override
_any_ LC_*/LANG variable and let the individual test modules use
LC_MESSAGES or LC_ALL if they rely on a specific message output or
locale.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) [email protected]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to