Why does LC_MESSSAGES need to be exported on macOS homebrew bash to take effect?
up vote
4
down vote
favorite
On macOS, with bash installed from homebrew, I noticed that setting LC_MESSAGES
seems to have some effect on the current shell's locale settings, but messages doesn't actually change until LC_MESSAGES
is exported:
Unsetting LANG
and LC_MESSAGES
, I get an English error message as expected:
bash-4.4$ unset LANG LC_MESSAGES
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Setting LC_MESSAGES
to an incorrect value gives an error about setlocale
:
bash-4.4$ LC_MESSAGES=foo
bash: warning: setlocale: LC_MESSAGES: cannot change locale (foo): No such file or directory
So something changes when I set LC_MESSAGES
. But setting it to a reasonable value has no effect:
bash-4.4$ LC_MESSAGES=ja_JP.UTF-8
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Until I export it:
bash-4.4$ export LC_MESSAGES
bash-4.4$ if :; fi
bash: 予期しないトークン `fi' 周辺に構文エラーがあります
(All of this goes for LANG
as well, it seems.)
The Bash manual's section on Bash Variables does not say LC_MESSAGES
or LANG
has to be exported (and most other variables listed there don't have to be exported).
Why is this?
bash osx locale homebrew
New contributor
|
show 7 more comments
up vote
4
down vote
favorite
On macOS, with bash installed from homebrew, I noticed that setting LC_MESSAGES
seems to have some effect on the current shell's locale settings, but messages doesn't actually change until LC_MESSAGES
is exported:
Unsetting LANG
and LC_MESSAGES
, I get an English error message as expected:
bash-4.4$ unset LANG LC_MESSAGES
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Setting LC_MESSAGES
to an incorrect value gives an error about setlocale
:
bash-4.4$ LC_MESSAGES=foo
bash: warning: setlocale: LC_MESSAGES: cannot change locale (foo): No such file or directory
So something changes when I set LC_MESSAGES
. But setting it to a reasonable value has no effect:
bash-4.4$ LC_MESSAGES=ja_JP.UTF-8
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Until I export it:
bash-4.4$ export LC_MESSAGES
bash-4.4$ if :; fi
bash: 予期しないトークン `fi' 周辺に構文エラーがあります
(All of this goes for LANG
as well, it seems.)
The Bash manual's section on Bash Variables does not say LC_MESSAGES
or LANG
has to be exported (and most other variables listed there don't have to be exported).
Why is this?
bash osx locale homebrew
New contributor
Possible duplicate of Difference between environment variables and exported environment variables in bash
– Scott
7 hours ago
@Scott thanks, but what am I supposed to see there? As I said, the documentation does not say the variable has to be exported, and setting an unexportedLC_MESSAGES
does have some effect. How does that post explain either of these observations?
– JohnDoea
7 hours ago
When you set a plain, ordinary, local shell variable, the shell just puts it into memory. TheLANG
andLC_*
variables are a special case; they get validated when assigned in a way that no (few?) other variables do. But the point is that variables don’t become visible (especially to external programs) and effective until they are exported, and transformed from shell variables into environment variables. … (Cont’d)
– Scott
7 hours ago
(Cont’d) … The fact that you need to do this to get bash itself to honor them is a little odd, but the explanation is probably that they are using library code (suitable for running in any program), and that library code calls other library functions likegetenv
, and there’s no mechanism for short-circuiting them to look for a shell variable calledLC_MESSAGES
when no environment variable by that name exists.
– Scott
7 hours ago
While I can't reproduce with 4.4 on GNU/Linux (changes taken into account when exported or not), I can on FreeBSD.
– Stéphane Chazelas
7 hours ago
|
show 7 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
On macOS, with bash installed from homebrew, I noticed that setting LC_MESSAGES
seems to have some effect on the current shell's locale settings, but messages doesn't actually change until LC_MESSAGES
is exported:
Unsetting LANG
and LC_MESSAGES
, I get an English error message as expected:
bash-4.4$ unset LANG LC_MESSAGES
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Setting LC_MESSAGES
to an incorrect value gives an error about setlocale
:
bash-4.4$ LC_MESSAGES=foo
bash: warning: setlocale: LC_MESSAGES: cannot change locale (foo): No such file or directory
So something changes when I set LC_MESSAGES
. But setting it to a reasonable value has no effect:
bash-4.4$ LC_MESSAGES=ja_JP.UTF-8
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Until I export it:
bash-4.4$ export LC_MESSAGES
bash-4.4$ if :; fi
bash: 予期しないトークン `fi' 周辺に構文エラーがあります
(All of this goes for LANG
as well, it seems.)
The Bash manual's section on Bash Variables does not say LC_MESSAGES
or LANG
has to be exported (and most other variables listed there don't have to be exported).
Why is this?
bash osx locale homebrew
New contributor
On macOS, with bash installed from homebrew, I noticed that setting LC_MESSAGES
seems to have some effect on the current shell's locale settings, but messages doesn't actually change until LC_MESSAGES
is exported:
Unsetting LANG
and LC_MESSAGES
, I get an English error message as expected:
bash-4.4$ unset LANG LC_MESSAGES
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Setting LC_MESSAGES
to an incorrect value gives an error about setlocale
:
bash-4.4$ LC_MESSAGES=foo
bash: warning: setlocale: LC_MESSAGES: cannot change locale (foo): No such file or directory
So something changes when I set LC_MESSAGES
. But setting it to a reasonable value has no effect:
bash-4.4$ LC_MESSAGES=ja_JP.UTF-8
bash-4.4$ if :; fi
bash: syntax error near unexpected token `fi'
Until I export it:
bash-4.4$ export LC_MESSAGES
bash-4.4$ if :; fi
bash: 予期しないトークン `fi' 周辺に構文エラーがあります
(All of this goes for LANG
as well, it seems.)
The Bash manual's section on Bash Variables does not say LC_MESSAGES
or LANG
has to be exported (and most other variables listed there don't have to be exported).
Why is this?
bash osx locale homebrew
bash osx locale homebrew
New contributor
New contributor
New contributor
asked 8 hours ago
JohnDoea
211
211
New contributor
New contributor
Possible duplicate of Difference between environment variables and exported environment variables in bash
– Scott
7 hours ago
@Scott thanks, but what am I supposed to see there? As I said, the documentation does not say the variable has to be exported, and setting an unexportedLC_MESSAGES
does have some effect. How does that post explain either of these observations?
– JohnDoea
7 hours ago
When you set a plain, ordinary, local shell variable, the shell just puts it into memory. TheLANG
andLC_*
variables are a special case; they get validated when assigned in a way that no (few?) other variables do. But the point is that variables don’t become visible (especially to external programs) and effective until they are exported, and transformed from shell variables into environment variables. … (Cont’d)
– Scott
7 hours ago
(Cont’d) … The fact that you need to do this to get bash itself to honor them is a little odd, but the explanation is probably that they are using library code (suitable for running in any program), and that library code calls other library functions likegetenv
, and there’s no mechanism for short-circuiting them to look for a shell variable calledLC_MESSAGES
when no environment variable by that name exists.
– Scott
7 hours ago
While I can't reproduce with 4.4 on GNU/Linux (changes taken into account when exported or not), I can on FreeBSD.
– Stéphane Chazelas
7 hours ago
|
show 7 more comments
Possible duplicate of Difference between environment variables and exported environment variables in bash
– Scott
7 hours ago
@Scott thanks, but what am I supposed to see there? As I said, the documentation does not say the variable has to be exported, and setting an unexportedLC_MESSAGES
does have some effect. How does that post explain either of these observations?
– JohnDoea
7 hours ago
When you set a plain, ordinary, local shell variable, the shell just puts it into memory. TheLANG
andLC_*
variables are a special case; they get validated when assigned in a way that no (few?) other variables do. But the point is that variables don’t become visible (especially to external programs) and effective until they are exported, and transformed from shell variables into environment variables. … (Cont’d)
– Scott
7 hours ago
(Cont’d) … The fact that you need to do this to get bash itself to honor them is a little odd, but the explanation is probably that they are using library code (suitable for running in any program), and that library code calls other library functions likegetenv
, and there’s no mechanism for short-circuiting them to look for a shell variable calledLC_MESSAGES
when no environment variable by that name exists.
– Scott
7 hours ago
While I can't reproduce with 4.4 on GNU/Linux (changes taken into account when exported or not), I can on FreeBSD.
– Stéphane Chazelas
7 hours ago
Possible duplicate of Difference between environment variables and exported environment variables in bash
– Scott
7 hours ago
Possible duplicate of Difference between environment variables and exported environment variables in bash
– Scott
7 hours ago
@Scott thanks, but what am I supposed to see there? As I said, the documentation does not say the variable has to be exported, and setting an unexported
LC_MESSAGES
does have some effect. How does that post explain either of these observations?– JohnDoea
7 hours ago
@Scott thanks, but what am I supposed to see there? As I said, the documentation does not say the variable has to be exported, and setting an unexported
LC_MESSAGES
does have some effect. How does that post explain either of these observations?– JohnDoea
7 hours ago
When you set a plain, ordinary, local shell variable, the shell just puts it into memory. The
LANG
and LC_*
variables are a special case; they get validated when assigned in a way that no (few?) other variables do. But the point is that variables don’t become visible (especially to external programs) and effective until they are exported, and transformed from shell variables into environment variables. … (Cont’d)– Scott
7 hours ago
When you set a plain, ordinary, local shell variable, the shell just puts it into memory. The
LANG
and LC_*
variables are a special case; they get validated when assigned in a way that no (few?) other variables do. But the point is that variables don’t become visible (especially to external programs) and effective until they are exported, and transformed from shell variables into environment variables. … (Cont’d)– Scott
7 hours ago
(Cont’d) … The fact that you need to do this to get bash itself to honor them is a little odd, but the explanation is probably that they are using library code (suitable for running in any program), and that library code calls other library functions like
getenv
, and there’s no mechanism for short-circuiting them to look for a shell variable called LC_MESSAGES
when no environment variable by that name exists.– Scott
7 hours ago
(Cont’d) … The fact that you need to do this to get bash itself to honor them is a little odd, but the explanation is probably that they are using library code (suitable for running in any program), and that library code calls other library functions like
getenv
, and there’s no mechanism for short-circuiting them to look for a shell variable called LC_MESSAGES
when no environment variable by that name exists.– Scott
7 hours ago
While I can't reproduce with 4.4 on GNU/Linux (changes taken into account when exported or not), I can on FreeBSD.
– Stéphane Chazelas
7 hours ago
While I can't reproduce with 4.4 on GNU/Linux (changes taken into account when exported or not), I can on FreeBSD.
– Stéphane Chazelas
7 hours ago
|
show 7 more comments
1 Answer
1
active
oldest
votes
up vote
0
down vote
Take a look at this answer for an explaination of the difference between a shell variable and an environment variable. In essence:
Setting a shell variable:
LANG=en_US.UTF-8
Setting an environment variable:
export LANG=en_US.UTF-8
You want to set environment variables for locale, as shell variables are private to the shell and won’t be passed to child processes.
New contributor
1
That's different here.export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.
– Stéphane Chazelas
7 hours ago
There are no child processes here, though. That's why I specifically used thisif :; fi
command, which generates a syntax error from the shell itself.
– JohnDoea
7 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as forsetlocale
telling Bash that it didn't work, there are two assignments here, andsetlocale
only complained about one of them. Going by your logic, it should have complained about both.
– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
|
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Take a look at this answer for an explaination of the difference between a shell variable and an environment variable. In essence:
Setting a shell variable:
LANG=en_US.UTF-8
Setting an environment variable:
export LANG=en_US.UTF-8
You want to set environment variables for locale, as shell variables are private to the shell and won’t be passed to child processes.
New contributor
1
That's different here.export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.
– Stéphane Chazelas
7 hours ago
There are no child processes here, though. That's why I specifically used thisif :; fi
command, which generates a syntax error from the shell itself.
– JohnDoea
7 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as forsetlocale
telling Bash that it didn't work, there are two assignments here, andsetlocale
only complained about one of them. Going by your logic, it should have complained about both.
– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
|
show 1 more comment
up vote
0
down vote
Take a look at this answer for an explaination of the difference between a shell variable and an environment variable. In essence:
Setting a shell variable:
LANG=en_US.UTF-8
Setting an environment variable:
export LANG=en_US.UTF-8
You want to set environment variables for locale, as shell variables are private to the shell and won’t be passed to child processes.
New contributor
1
That's different here.export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.
– Stéphane Chazelas
7 hours ago
There are no child processes here, though. That's why I specifically used thisif :; fi
command, which generates a syntax error from the shell itself.
– JohnDoea
7 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as forsetlocale
telling Bash that it didn't work, there are two assignments here, andsetlocale
only complained about one of them. Going by your logic, it should have complained about both.
– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
|
show 1 more comment
up vote
0
down vote
up vote
0
down vote
Take a look at this answer for an explaination of the difference between a shell variable and an environment variable. In essence:
Setting a shell variable:
LANG=en_US.UTF-8
Setting an environment variable:
export LANG=en_US.UTF-8
You want to set environment variables for locale, as shell variables are private to the shell and won’t be passed to child processes.
New contributor
Take a look at this answer for an explaination of the difference between a shell variable and an environment variable. In essence:
Setting a shell variable:
LANG=en_US.UTF-8
Setting an environment variable:
export LANG=en_US.UTF-8
You want to set environment variables for locale, as shell variables are private to the shell and won’t be passed to child processes.
New contributor
New contributor
answered 7 hours ago
Richard Barber
1095
1095
New contributor
New contributor
1
That's different here.export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.
– Stéphane Chazelas
7 hours ago
There are no child processes here, though. That's why I specifically used thisif :; fi
command, which generates a syntax error from the shell itself.
– JohnDoea
7 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as forsetlocale
telling Bash that it didn't work, there are two assignments here, andsetlocale
only complained about one of them. Going by your logic, it should have complained about both.
– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
|
show 1 more comment
1
That's different here.export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.
– Stéphane Chazelas
7 hours ago
There are no child processes here, though. That's why I specifically used thisif :; fi
command, which generates a syntax error from the shell itself.
– JohnDoea
7 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as forsetlocale
telling Bash that it didn't work, there are two assignments here, andsetlocale
only complained about one of them. Going by your logic, it should have complained about both.
– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
1
1
That's different here.
export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.– Stéphane Chazelas
7 hours ago
That's different here.
export
is only needed to affect the behaviour of commands being executed. Here, we're talking of messages generated by the shell internally.– Stéphane Chazelas
7 hours ago
There are no child processes here, though. That's why I specifically used this
if :; fi
command, which generates a syntax error from the shell itself.– JohnDoea
7 hours ago
There are no child processes here, though. That's why I specifically used this
if :; fi
command, which generates a syntax error from the shell itself.– JohnDoea
7 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
It is the assignment that creates the problem. Assignment of a variable is a command that gets forked off. The setlocale child process doesn’t see the shell variable assignment and told bash that it didn’t work. Bash reported the assignment didn’t work, and told you what your attempted assignment was.
– Richard Barber
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as for
setlocale
telling Bash that it didn't work, there are two assignments here, and setlocale
only complained about one of them. Going by your logic, it should have complained about both.– JohnDoea
5 hours ago
That ... makes no sense. Simple variable assignment doesn't fork off a new process in any shell that I know of. And as for
setlocale
telling Bash that it didn't work, there are two assignments here, and setlocale
only complained about one of them. Going by your logic, it should have complained about both.– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
That's not "simple" variable assignment, though, is it? You're running that in the background.
– JohnDoea
5 hours ago
|
show 1 more comment
JohnDoea is a new contributor. Be nice, and check out our Code of Conduct.
JohnDoea is a new contributor. Be nice, and check out our Code of Conduct.
JohnDoea is a new contributor. Be nice, and check out our Code of Conduct.
JohnDoea is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f482084%2fwhy-does-lc-messsages-need-to-be-exported-on-macos-homebrew-bash-to-take-effect%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Possible duplicate of Difference between environment variables and exported environment variables in bash
– Scott
7 hours ago
@Scott thanks, but what am I supposed to see there? As I said, the documentation does not say the variable has to be exported, and setting an unexported
LC_MESSAGES
does have some effect. How does that post explain either of these observations?– JohnDoea
7 hours ago
When you set a plain, ordinary, local shell variable, the shell just puts it into memory. The
LANG
andLC_*
variables are a special case; they get validated when assigned in a way that no (few?) other variables do. But the point is that variables don’t become visible (especially to external programs) and effective until they are exported, and transformed from shell variables into environment variables. … (Cont’d)– Scott
7 hours ago
(Cont’d) … The fact that you need to do this to get bash itself to honor them is a little odd, but the explanation is probably that they are using library code (suitable for running in any program), and that library code calls other library functions like
getenv
, and there’s no mechanism for short-circuiting them to look for a shell variable calledLC_MESSAGES
when no environment variable by that name exists.– Scott
7 hours ago
While I can't reproduce with 4.4 on GNU/Linux (changes taken into account when exported or not), I can on FreeBSD.
– Stéphane Chazelas
7 hours ago