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?










share|improve this question







New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • 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 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










  • 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















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?










share|improve this question







New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • 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 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










  • 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













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?










share|improve this question







New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question







New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 8 hours ago









JohnDoea

211




211




New contributor




JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






JohnDoea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • 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 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










  • 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










  • @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










  • (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
















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










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.






share|improve this answer








New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 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 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










  • 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











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






JohnDoea is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















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

























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.






share|improve this answer








New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 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 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










  • 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















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.






share|improve this answer








New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 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 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










  • 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













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.






share|improve this answer








New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









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.







share|improve this answer








New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 7 hours ago









Richard Barber

1095




1095




New contributor




Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Richard Barber is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 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 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










  • 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














  • 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 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










  • 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








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










JohnDoea is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















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.















 


draft saved


draft discarded














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





















































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







Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt