> Aleksey Cheusov wrote:
 >> > On Thu, Apr 27, 2006 at 09:53:56PM +0300, Aleksey Cheusov wrote:
 >>  >> What do you think about the following patch for nawk?
 >>  >> With this patch applied, awk will exit with error
 >>  >> if LANG or LC_ variable are set to incorrect value,
 >> 
 >> > Incorrect locale settings are softerrors, since it is entire
 >> > possible that a single part of a locale is not defined. setlocale()
 >> > is well-behaving in that regard, it falls back to "C", as if nothing
 >> > had happened.
 >> With this "softerror" scripts that rely on locale
 >> work _completely_ incorrect with no chance of signaling
 >> user about errors.

> IMO, your rendering is too strict, and ignoring the return code (and
> requiring the script to rely on something external, e.g. locale(1)) is too
> lax.  Nothing says awk *needs* a locale, but it's dismal to force a script
> to work in ignorance when the interpreter is perfectly aware of the locale
> status.  

> The script should have a way -- preferably an awk way -- to discover
> whether or not the locale is broken for its purposes.  After all, things
> like toupper() are affected by the language being represented in by the
> character set.  

> What about defining a built-in variable, say, LOCALE to something
> meaningful when the locale is OK?  Or a die-on-warning option like Perl
> and gcc use?  
I know how to check whether locale is set corectly or not.  Of cource
it is possible to test it in awk and shell and whatever.
But I think that it is much
easier to fix a bug in one place (awk, tr, sed, ...) than fixing it in
tons of my scripts I already have and all future ones.
I don't insist that return value of setlocale(3) must always be treated
as critical error, but I see some cases when this feature
can be very useful. As I already said an easiest way to implement
both approaches is to test a special environment variable
"treat_setlocale_failure_as_critical_bug" that can be set
in the user profile ones for a session.

-- 
Best regards, Aleksey Cheusov.