But I don’t want to set the locale, I was was simply trying to read it in.
I was working on an Xcode project, and noticed the same behaviour when calling out to the command line from that project, and then tested it again in AppleScript, and found the same behaviour there as well.
So using “system info” is not an option for the Xcode project, as I will have to find another way to read in the locale.
Although I’m still very interested in knowing why the posted command gets a result in Terminal.
But does not return a result when calling from an AppleScript or other code.
Thanks for making that clearer, I have to be honest I didn’t get that point made by marc, so apologies to him.
It wasn’t the getting or setting of the language or locale that was puzzling me, but the different results obtained from where you called the same shell command.
But now it kind of makes sense with what you and marc have said, that different processes are potentially using different shell’s, and that the locale may have been set by the Terminal app in it’s default shell, but that the same locale variables may not have been set in other shell processes.
You get the same behaviour with the “locale” shell command as well, when typed into the Terminal, or run as an AppleScript “do shell script”.
set result to do shell script "locale"
I’ve sorted out the problem in my Xcode project, using the Swift Locale class, used in a similar way to the NSLocale class above.
But it’s been puzzling and interesting in equal measure.
I decided to take a test to check the claim that the problem is that Terminal and do shell script are using different shells. To do this, I:
executed the command “/bin/sh” in Terminal (the shell used by the do shell script), and then the command “echo $LANG”. The result was “”.
I created a .zprofile configuration text file in my home folder with the following content:
# Setting LANG for do shell script
LANG = “en_EN.UTF-8”
Then I ran the command “/bin/sh” in Terminal again, and then the command “echo $LANG”. The result was “en_EN.UTF-8” (that is, I achieved what I wanted using the fact that Terminal reads user config files when available).
I expected the do shell script to output the locale after that, but I got “” again. And then I realized that the do shell script does not read configuration files, unlike Terminal.
In the do shell script technical notes, I found confirmation of this observation: do shell script does not read configuration files.
And here is my answer: the difference in the behavior of the Terminal and the do shell script is that the first takes data from the configuration files (when available), and the second does not. Even if you use the same shell.