I hope I don't getting on your nerves, but your explanation do not fit to my observations. Before I set "LC_LANG=C" in the environment.plist I got the mentioned error message by example after I entered "perl -v" in a terminal window by example. There is no 'use locale' pragma but perl didn't ignored the "LANG=de" setting in my shell environment.
With these settings (LC_ALL unset, LANG=de in the shell environment) I did a
bash-2.05a$ ktrace -f kdump.out perl -v
bash-2.05a$ kdump -f ktrace.out
to see what happens. I got
...
871 perl CALL open(0xbffff600,0,0x1b6)
871 perl NAMI "/usr/share/locale/de/LC_COLLATE"
871 perl RET open -1 errno 2 No such file or directory
871 perl CALL write(0x2,0xc360,0x26)
871 perl GIO fd 2 wrote 38 bytes
"perl: warning: Setting locale failed.
...
As you can see, perl is trying to open a file "/usr/share/locale/de/LC_COLLATE" that can't be found. This is the immediate cause of the error message. Such a file (it has to do with the sorting rules, right) exists in other unix derivates and you can create you own LC_COLLATE file in Linux or Solaris. I was looking for a way to do the same thing in OS X. (Or a appropriate pre-built version, or another procedure that solves the problem.)
In short: Perl respects the LANG-variable in the environment, even if you do not use a locale pragma and it is definitively searching for a missing file LC_COLLATE.
By the way, I read perldoc perllocale. Maybe I misunderstood something?
Jens-Christoph
Am Mittwoch, 15.01.03 um 06:47 Uhr Robin wrote:
On Wednesday, January 15, 2003, at 04:26 AM, Jens-Christoph Brendel wrote:
..... The problem remains that with this method only the "C" locale can be set correctly. Files for certain parts of a complete locale definition (e.g. LC_COLLATE) are missing. Perl looks for LC_COLLATE and shows the cited error message just because this can't be found. It's therefore impossible to use other language specific locales than "C" (for example "de_DE" as I tried).Assuming that the errors you mention are the same as your original post, you don't need to compile locales. On OSX the locales are stored in /usr/share/locale, this is what I get when I type 'ls /usr/share/locale':
C en_GB.ISO8859-15 hr_HR.ISO8859-2 no
...
8859-1
de es_ES.ISO8859-1 it_IT pt_PT.ISO8859-15
de_AT es_ES.ISO8859-15 it_IT.ISO8859-1 ru
de_AT.ISO8859-1 fi it_IT.ISO8859-15 ru_RU.CP866
de_AT.ISO8859-15 fi_FI ja ru_RU.ISO8859-5
de_CH fi_FI.ISO8859-1 ja_JP.EUC ru_RU.KOI8-R
de_CH.ISO8859-1 fi_FI.ISO8859-15 ja_JP.SJIS ru_RU.cp1251
de_CH.ISO8859-15 fr ko ru_RU.koi8r
de_DE fr_BE ko_KR.EUC sl
de_DE.ISO8859-1 fr_BE.ISO8859-1 la_LN.ISO8859-1 sl_SI.ISO8859-2
de_DE.ISO8859-15 fr_BE.ISO8859-15 la_LN.ISO8859-15 sv
<from Perllocale - numbers added by me>
[1] By default, Perl ignores the current locale. The `use locale' pragma tells Perl to use the current locale for some operations:
...
[2] In the scope of `use locale', Perl looks to the `LC_COLLATE' environment variable to determine the application's notions on collation (ordering) of characters.
</from Perllocale>
so in [1] it's saying reguardless of what locale you use outside perl, unless you tell perl otherwise, it uses the LC_ALL='C' locale.
[2] when you try to 'use locale ', perl looks for an Environment variable called LC_COLLATE
So the solution is to set any Environment variables perl complains about, and their values, into the system.plist (which is global, unlike the alternative of setting them in a terminal startup file), by hand, with the Dev Tools Plist Editor or the perl script (duly modified to match your needs ) from the post at http:[EMAIL PROTECTED]/msg03130.html, as you prefer.
It wouldn't hurt to read through perllocale too :-)
HTH
Robin
