Hi, Thanks.
On Mon, Oct 29, 2012 at 01:06:57PM +0100, Olivier Berger wrote: > Package: debian-reference > Severity: normal > > The following is the contents of the > http://www.debian.org/doc/manuals/debian-reference/ch01.en.html#_literal_lang_literal_variable > chapter. > > However, I find it weird, and not really compliant to what I can see on my > system. > > Typical command execution uses a shell line sequence as the following. > > $ date > Sun Jun 3 10:27:39 JST 2007 > $ LANG=fr_FR.UTF-8 date > dimanche 3 juin 2007, 10:27:33 (UTC+0900) > > Here, the program date(1) is executed with different values of the > environment variable "$LANG". > > For the first command, "$LANG" is set to the system default locale value > "en_US.UTF-8". > > For the second command, "$LANG" is set to the French UTF-8 locale value > "fr_FR.UTF-8". > > Most command executions usually do not have preceding environment variable > definition. For the above example, you can alternatively execute as the > following. Who said this? I do not agree. Although I never have experience, I understand this style always worked on Unix shell historically. > $ LANG=fr_FR.UTF-8 > $ date > dimanche 3 juin 2007, 10:27:33 (UTC+0900) > As you can see here, the output of command is affected by the environment > variable to produce French output. If you want the environment variable to be > inherited to subprocesses (e.g., when calling shell script), you need to > export it instead by the following. > > $ export LANG > > When in a user's terminal, typically, it seems to me that given that LANG is > already exported ('export -p' reports 'declare -x LANG="en_US.UTF-8"'), there > is no need to do another additional export LANG. This is a very good point for recent installalation. But do you get this even if you chose default locale to be C (or None). > I think it would make more sense to write this the following way : > > Typical command execution uses a shell line sequence as the following. > > $ date > Sun Jun 3 10:27:39 JST 2007 > > Here, the program date(1) is executed with a value of the environment > variable "$LANG" set to the system default locale value "en_US.UTF-8". > > We can change that variable to the French UTF-8 locale value "fr_FR.UTF-8" : > $ export LANG > $ LANG=fr_FR.UTF-8 > $ date > dimanche 3 juin 2007, 10:27:33 (UTC+0900) > > Note that it is generally not needed to explicitely export LANG, as it is > already marked as being exported in the shell environment (check with export > -p). > > In the above, as the LANG is now set to fr_FR.UTF-8 in the current shell > context, it will apply to all further subprocess launched (e.g., when calling > shell script). > > If you don't want to change it for the rest of the command invocations, but > want to limit the setting of LANG for the invocation of a single command, you > may instead use a preceding environment variable definition as in : > > $ LANG=fr_FR.UTF-8 date > dimanche 3 juin 2007, 10:27:33 (UTC+0900) > $ date > Sun Jun 3 10:27:39 JST 2007 > > I wonder if this hasn't been somehow like this in the past, as the current > initial example has dates in a non-chronologic sequence, apparently :-/ output for date field of the ls command seems to have fluctuated recently for some locale but... I do not understand what you mean by "non-chronologic sequence". You mean English and French sequence? As I recheck output, they are the same: OLD: Sun Jun 3 10:27:39 JST 2007 NOW: Mon Nov 5 21:28:22 JST 2012 OLD: dimanche 3 juin 2007, 10:27:33 (UTC+0900) NOW: lundi 5 novembre 2012, 21:29:12 (UTC+0900) > Hope this helps. Why skip preceding environment variable style. It see very good educational value. It is one time only even if variable is exported. Please you read the following text of the section we discuss. It goes as: Tip When filing a bug report, running and checking the command under "LANG=en_US.UTF-8" is good idea if you use non-English environment. For this, I wish to use "LANG=en_US.UTF-8 some-command" so your following activity will be as you always have. So this is intentional choice of text by the author. > Best regards, Thanks for your comment. In conclusion, I will think about suggesting $LANG may be exported when one is on a user's terminal. Something for footnote. Regards, Osamu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
