Warum wird "LANG = C; sudo apt-get clean" usw. empfohlen?

16

Ich bin auf diese Wiki-Seite gestoßen : Package Manager Troubleshooting Procedure .

Darin gab es Befehle wie:

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

Wozu also LANG=C;?

package-management locale Gerechtigkeit für Monica
quelle
3
Einige verwandte Fragen: 1. LANG = C befindet sich in einer Reihe der Skripte /etc/init.d/*. Was macht LANG = C und warum muss LANG = C eingestellt werden? , 2. Warum "LANG = C"? (nicht D oder E oder F) , 3. http://unix.stackexchange.com/questions/87745/what-does-lc-all-c-do .
Usmanayubsh
8
Bitte beachten Sie, dass dieses Dokument den Befehl falsch verwendet - es sollte LANG=C commandund nicht LANG=C;command. Das erste Formular erzwingt den Wert der LANGUmgebungsvariablen für die Dauer, commandwährend das zweite Formular eigentlich zwei Befehle umfasst, wobei der erste Teil nur eine lokale (nicht exportierte) Variable festlegt und der zweite Teil den Befehl ausführt, ohne die erforderliche Umgebungsvariable festzulegen.
Guss
2
@Guss: Eigentlich funktioniert es auch mit dem Semikolon. Warum? Da LANG eine vorhandene Umgebungsvariable ist, wenn Sie das Terminalfenster öffnen und den Wert als separaten Befehl ändern, ist dieser Wert die effektive Umgebungsvariable, bis Sie ihn erneut ändern oder der Prozess endet.
Gunnar Hjalmarsson
3
@Gunnar - es ist falsch: Befindet sich wahrscheinlich LANGin der Umgebung, funktioniert also wahrscheinlich mit redundanten Semikolons; aber es ist (1) redundant, weil sich LANGzwischen den Befehlen nichts ändern wird . Der Hinweis, dass jemand Befehle auf diese Weise ausführen soll, ist (2) falsch, weil sich die Umgebung unnötig und ungebeten ändert, und (3) dies liefert ein falsches Muster für jeden nicht informierten Benutzer, der die Verwendung später erneut anwendet - möglicherweise mit einer Shell-Variablen, die sich nicht in befindet die Umgebung und damit auch keine Auswirkungen auf die ausgeführten Befehle, die für eine korrekte, möglicherweise sichere Funktion erforderlich sind.
FooF
2
@Braiam Ich bin mit der Syntax vertraut, aber es ist wichtig zu beachten, dass der Befehl sie nur dann sieht, wenn die Variable exportiert wird. LANG ist eine Standard-Umgebungsvariable und wird daher standardmäßig exportiert. Andere Variablen werden jedoch möglicherweise nicht exportiert, und das OP sollte sich dessen bewusst sein.
Guss

Antworten:

26

Bei der Fehlerbehebung werden Sie Ihre Ergebnisse wahrscheinlich früher oder später in einem Forum oder hier veröffentlichen.

In diesem Fall ist es für andere Benutzer viel einfacher, Ihre Protokolle und Ausgaben zu verstehen, wenn sie nicht internationalisiert sind.

Das heißt, wenn Sie Französisch oder Chinesisch oder Hindi oder was auch immer als Ihre Systemsprache verwenden, wird die Ausgabe wahrscheinlich Begriffe in dieser Sprache verwenden, und das macht es umso schwieriger zu verstehen, was vor sich geht.

Das Gebietsschema C erzwingt die Standardausgabe (normalerweise nur ASCII-Englisch).

Am besten starten Sie eine Fehlerbehebungssitzung mit:

export LC_ALL=C

Anstatt bestimmte Gebietsschemavariablen oder nur für einen bestimmten Befehl festzulegen.

muru
quelle
10

LANG=CDadurch wird die Terminalausgabe auf das Standardgebietsschema zurückgesetzt. Da dieses Handbuch vorschlägt, dass Sie Ihre Ausgabe zur Unterstützung an Launchpad senden, müssen Sie dies tun, damit andere Benutzer sie lesen können, wenn Sie sie einfügen, unabhängig davon, welche Sprache Sie normalerweise verwenden.


quelle
3

Ein kleiner Zusatz, obwohl er bei apt wahrscheinlich nicht zutrifft, da ich ihn als ziemlich stabile Software betrachte:

Einige Programme verhalten sich notorisch falsch, wenn sie eine andere Einstellung für LANG verwenden (oder zumindest eine andere als C oder en_US).

Unity hatte (noch?) Diese Probleme (und Unity-basierte Spiele), auch Unreal Engine hatte einige Probleme. Auch einige der Build-Skripte für Android liefen nur mit LANG = C ordnungsgemäß oder wurden nur mit dieser Umgebungsvariablen kompiliert, die auf diese Weise festgelegt wurde.

Dies könnte auch zur Fehlerbehebung beitragen, da der Fehler bei dieser Einstellung möglicherweise gar nicht auftritt.

Larkey
quelle