16

I came across this wiki page: Package Manager Troubleshooting Procedure.

In it, there were commands such as:

LANG=C;sudo apt-get clean
LANG=C;sudo apt-get autoclean
LANG=C;sudo apt-get -f install
LANG=C;sudo apt-get --fix-missing install
LANG=C;sudo apt-get --purge autoremove
LANG=C;sudo apt-get --fix-missing update -o APT::Cache-Limit=100000000
LANG=C;sudo apt-get update -o APT::Cache-Limit=100000000 && sudo apt-get dist-upgrade

So what is the purpose of LANG=C;?

muru
  • 207,970
DK Bose
  • 44,703
  • 3
    A few related questions: 1. LANG=C is in a number of the /etc/init.d/* scripts. What does LANG=C do and why do you need to set LANG=C?, 2. Why “LANG=C”? (not D or E or F), 3. http://unix.stackexchange.com/questions/87745/what-does-lc-all-c-do. – usmanayubsh Jan 26 '16 at 14:46
  • 9
    Please note that that document is using the command incorrectly - it should be LANG=C command and not LANG=C;command. The first form forces the value of LANG environment variable for the duration of command while the second form is actually two commands where the first part just sets a local (not exported) variable and the second part runs the command without setting the required environment variable. – Guss Jan 26 '16 at 22:59
  • 2
    @Guss: Actually it works also with the semicolon. Why? Because LANG is an existing environment variable when you open the terminal window, and if you change its value as a separate command, that value will be the effective environment variable until you change it again or the process ends. – Gunnar Hjalmarsson Jan 27 '16 at 02:03
  • 3
    @Gunnar - it is incorrect: Probably LANG is in the environment, so it probably works with redundant semicolons; but it is (1) redundant because nothing is going to change LANG between the commands. Also hinting somebody to run commands in such way is (2) wrong because of unnecessarily and uninvited changing environment, and (3) this provides an incorrect pattern for any uninformed user that later reapplies the usage - possibly with a shell variable that is not in the environment and thus not even having any effect on the commands run that require it for correct, perhaps safe, function. – FooF Jan 27 '16 at 04:56
  • It is a good question, but with the buggy inclusion of ; I do not think it should be upvoted due to risk of giving wrong example. – FooF Jan 27 '16 at 04:58
  • @Guss it actually sets the LANG variable to C, just that it's permanent, instead of per-command. – Braiam Jan 27 '16 at 10:26
  • 2
    @Braiam I'm familiar with the syntax, but it's important to note that unless the variable is exported, the command will not see it. LANG is a standard environment variable and so exported by default - but other variables may not be and the OP should be aware of that. – Guss Jan 27 '16 at 11:09
  • why LANG=C;sudo apt-get and not LANG=C sudo apt-get? – Rui F Ribeiro Jan 27 '16 at 14:33
  • @FooF, @Rui F Ribeiro, LANG=C; is how it was written in the wiki I linked to. I did not modify anything except that I omitted from my question the commands that didn't mention LANG=C;. – DK Bose Jan 27 '16 at 14:48
  • @Guss: For the reason I said, with LANG as a separate command (e.g. LANG=C ;) it's changed between the commands, and it's redundant to prepend the subsequent commands with LANG=C ;. So even if the example in the question works, it's indeed misleading, and I agree with you and others here that it was motivated to point it out. The page EnvironmentVariables explains it better. – Gunnar Hjalmarsson Jan 27 '16 at 19:03
  • 1
    @DKBose - I created account to fix the wiki page, but found the page in question was immutable. – FooF Jan 28 '16 at 03:27
  • @FooF, thanks for trying. Maybe editing that page needs special privileges? – DK Bose Jan 28 '16 at 04:22
  • @FooF, I tried as well and got the immutable thing. I recall reading about a recent hacking (?) event which may have led to a restriction on who can do what. – DK Bose Jan 28 '16 at 10:07
  • Maybe someone like @bodhi.zazen can help? – DK Bose Jan 28 '16 at 10:11
  • 1
    @FooF please look at http://ubuntuforums.org/showthread.php?t=2308813 re. the lockdown of wiki pages. – DK Bose Jan 28 '16 at 11:39

3 Answers3

26

If you're troubleshooting, you'll likely post your results in some forum, or here, sooner or later.

When that happens, it's much more simpler for other users to understand your logs and output, if they're not internationalised.

That's to say, if you're using French or Chinese or Hindi or whatever as your system language, the output is likely to use terms in that language, and that makes it all the more harder to understand what's going on.

The C locale forces default output (which is typically ASCII-only English).

It's best to start a troubleshooting session with:

export LC_ALL=C

Instead of setting specific locale variables, or setting it just for a specific command.

Community
  • 1
muru
  • 207,970
10

LANG=C will make your terminal output fall-back to the default locale. As this guide suggests you sending your output to Launchpad for support, they are having you do this so that, when you paste it in, others will be able to read it no matter what language you usually use.

3

A small addition although it probably doesn't apply in the case of apt as I regard it as a quite stable piece of software:

Some programs notoriosly misbehave when using a different setting for LANG (or atleast different from C or en_US).

Unity had (still has?) these issues (and Unity-based games), Unreal Engine had some problems too. Also some of the build-scripts for Android only ran with LANG=C properly or compiled only with this environment variable set this way.

So this could also help troubleshooting as the bug might not even occur with this setting.

ElleJay
  • 845