On Mon, 2006-01-09 at 11:03 -0500, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > AFAICT, perl doesn't keep any state about locale settings, it just > > reacts to whatever the current settings are, I think, but I could be wrong. > > If that's the case, why would it be bothering to issue setlocale during > startup at all? If you look in locale.c in the Perl sources, it's > pretty clear that it saves away state about the settings during > Perl_init_i18nl10n(). I'm too lazy to track down where that state is > used or what the consequences are if it's wrong, but it sure looks to > me like *something* will be broken if we just change the locale back > to what we want afterward. >
I don't know. Reading that code just makes my head spin ... I should have thought a library shouldn't make too many assumptions about locale settings anyway. What is to prevent another library from doing the same thing. Then we'd have duelling settings, dependent on who got called last. I had thought, from reading perl's locale.c, that unsetting LC_COLLATE and LANG would inhibit the calls to setlocale(LC_ALL,"") and setlocale(LC_COLLLATE,""). But my testing seemed to prove that wrong. Of course, it's possible that ActiveState's perl is not doing quite the same thing. At any rate, what I think we know from that code is that on Windows, just setting LANG and LC_* is precisely the wrong thing, since the presence of those values will trigger a call to setlocale(LC_foo,"") but the relevant environment value will not actually be used. I'm just about out of ideas and right out of time to spend on this. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
