On 3/30/25 2:34 AM, Robert Elz wrote:
Date:Thu, 27 Mar 2025 17:22:03 -0400
From:Chet Ramey
Message-ID: <6da17a73-2aac-4fa5-9fa7-5bfff087d...@case.edu>
| The shell should assume that setting a shell variable means the
| user wants to modify the shell's locale settings.
Yes, of course, the question is exactly what the user wants &/or what
the shell should impose on the user.
| > One answer would be "nothing"
| A bad choice.
I agree, though that would make the shell operate the way just
about all other programs behave, for example, if one does
ENVIRON["LC_NUMERIC"] = "whatever"
in awk, while that should appear in the environment of something
awk runs for a system() operation, it doesn't affect the way awk
works, or its numeric input or output, any way at all.
| The shell does quite a lot of things that are different than any other
| application, including allowing the user to change locale environment
| variables.
Yes, but it is not entirely alone in that. awk/make/env/... allow the
environment to be altered, but none of them notice that it is a locale
environment variable that is being altered, and adapt their own behaviour
to match, or none that I'm aware of, so having shells do the same would
not necessarily be all that remarkable, even if it is perhaps sub-optimal.
That's obviously an implementation choice, and can happen to various
degrees. For instance, GNU awk understands the TEXTDOMAIN variable and
provides builtin functions for translating messages, but doesn't look at
LC_* or LANG except at startup. There's not really much in make that would
be modified based on changing locale variables, and nothing at all in env.
However, languages like, say, python that allow users to set variables do
offer methods to change the interpreter behavior based on programmers
setting variables or calling builtin locale functions.
| That doesn't have to be all the shell does. The precedence hierarchy is
| well-understood; there's nothing stopping the shell from implementing it:
No there's not, but I'm not sure that's the ideal result. For example,
if a script does LC_CTYPE=C (or something similar) should it break if the
user happened to have set LC_ALL=something-different in the environment?
What does `break' mean?
If any other program does setlocale(LC_CTYPE, "C"); that has effect
for any future operations, regardless of what might have been in the
environment, why should a shell script be different?
Because the shell exposes the locale settings in a different way, offering
the user more flexibility?
| noting that LC_ALL is set as a shell variable and making the right call
| to setlocale() to make sure it overrides LC_CTYPE. I'd argue that having
| just set LC_ALL, this is what the user expects here.
That's something like what I tried in my first attempt to implement
this, but it turns out not to really work very well.
I think it works just fine, and bash users expect this behavior.
Certainly if
the user actually sets LC_ALL that is the effect it should have, but
if LC_ALL was set sometime much earlier (perhaps weeks earlier in an
interactive shell) what do you believe is the intent if that user later
sets LC_CTYPE (or any of them) - or if some script that is run does that?
I believe that users have agency, and that bash should trust that they know
what they're doing.
I know setting LC_ALL is something of a sledge hammer operation, which
isn't often appropriate, but it is also a fairly common example that
people copy (it avoids needing to work out which specific category
is affecting some operation or other).
OK. There's plenty of copypasta that has tripped up users before. Can the
shell protect them from that?
| You're assuming a certain behavior and going on from there. The shell
| doesn't have to do it that way.
Again, no it doesn't, but it seemed to me when I tried it, that this
way gives the most desirable outcome.
| I'd argue that the shell should modify the locale categories that affect
| its behavior.
How do we know which they are? That is, locale settings can affect
libc operations in some cases, and if we're writing portable code
(which bash at least attempts to do, the NetBSD shell a little less
so) can you really be sure that some libc function that is being
used won't be affected by a locale setting that you've never heard of?
You really can't. All you can do is document the locale categories you
use, and which ones you modify based on shell variables. If the user sets
an environmnent variable, say, LC_NAME (one of the GNU libc extensions),
that's not going to affect the shell's behavior because the shell won't
call setlocale(LC_NAME, whatever). If LC_NAME is in the environment when
the shell starts, and setlocale(LC_ALL, "") pays attention to it, I'd
argue that that's the user's intent.
That's no issue at all if the shell just does setlocale(LC_ALL, "");
as part of
