1 |
On Wednesday 11 May 2011 22:14:55 Mike Edenfield wrote: |
2 |
|
3 |
> The only problem with LC_ALL is that it overrides all of the other LC_* |
4 |
> variables. |
5 |
|
6 |
- which is precisely what most ordinary desktop users want. In such a case it's |
7 |
a useful shorthand. Personally, I have no intention of ever allowing US |
8 |
"English" to pollute any of my boxes (no offence meant to anyone here), so |
9 |
LC_ALL="en_GB.UTF-8" suits me (so far - until I trip over something!). |
10 |
|
11 |
> Setting just LANG= and setting just LC_ALL= have the same ultimate result: |
12 |
> every localization category uses the same locale. |
13 |
|
14 |
I knew a manager some years ago* who tried hard to persuade his bosses that he |
15 |
could be in two places at once - he even had two fish-huts! He was usually to be |
16 |
found in the same time-zone though, for all that. |
17 |
|
18 |
> The difference is that setting LC_ALL means you can't turn around and redefine, |
19 |
> say, just LC_TIME to use some other locale's format. |
20 |
|
21 |
This isn't going to be the majority case though, is it? I'm not talking about |
22 |
globe-trotting laptops here; just your ordinary desktop box. |
23 |
|
24 |
You can tell from my tone, I hope, that I'm only half-serious, but still I can't |
25 |
see why the simple approach should be frowned on so severely. What practical |
26 |
benefit do I lose by setting LC_ALL once and for all? This machine has been in |
27 |
the same place all its life, and I'm confident that won't change. The same |
28 |
applies to my other machines. I say it's time for document writers to recognise |
29 |
two cases explicitly: static machines and mobile ones. |
30 |
|
31 |
* He worked 24 hours/day for a mainframe system integrator near Minneapolis. |
32 |
That didn't stop it going down the pan when its marketing department failed to |
33 |
see the direction of the prevailing wind in its most important contract ever. |
34 |
|
35 |
-- |
36 |
Rgds |
37 |
Peter |