staging.inyokaproject.org

Hallo,

der Artikel wurde in diesem Thread als fertig gemeldet.

Anmerkungen:

Ich halte es noch wie vor für schlecht, dass Umgebungsvariable(n) durch UV abgekürzt wird, zumal wir im Wiki Abkürzungen weitestgehend vermeiden. Bitte durchgängig ausschreiben.

Es gibt einen kurzen Abschnitt im Artikel, der sich auf < 14.04 bezieht → kann weg.

Den Satz "Um PATH dauerhaft und systemweit zu erweitern, muss die Datei /etc/environment editiert werden. Entsprechend muss benutzerspezifisch die Datei ~/.profile bearbeitet werden." verstehe ich nicht. Worauf bezieht sich "entsprechend"? Das man /etc/environment _und_ .profile bearbeiten muss.

Teileweise stehen Befehle in Codeblöcken und Ausgaben in Befehlsboxen.

Das Skript unter "Aufruf-Hierarchie anzeigen" sagt, dass jemand da Copyright drauf hat. Mal abgesehen davon, dass ich persönlich das Skript von der Schöpfungshöhe nicht für so genial halte, dass es in irgendeiner Form schützenswert ist: wenn das was geschützt werden soll, sollte der Autor ein Lizenz angeben, unter der das Skript steht.

Ich finde die Trennung im Artikel zwischen "typische Anwendungsfälle" (BTW: wer legt überhaupt fest, was "typisch" ist?) und "weitere Praxisbeispiele" künstlich. IMHO sollte das weg und der ganze Artikel "praktische Anwendungsfälle" oder "praktische Anwendungsbeispiele" heißen.

Gruß, noisefloor

Hallo,

noisefloor schrieb:

Hallo, der Artikel wurde in diesem Thread als fertig gemeldet.

nicht explizit, war auch für diesen Artikel nicht so gemeint. Wollte hier schon nochmal drüber schauen.

Anmerkungen: Ich halte es noch wie vor für schlecht, dass Umgebungsvariable(n) durch UV abgekürzt wird, zumal wir im Wiki Abkürzungen weitestgehend vermeiden.

da bin ich voll bei dir.

Es gibt einen kurzen Abschnitt im Artikel, der sich auf < 14.04 bezieht → kann weg.

ok

Den Satz "Um PATH dauerhaft und systemweit zu erweitern, muss die Datei /etc/environment editiert werden. Entsprechend muss benutzerspezifisch die Datei ~/.profile bearbeitet werden." verstehe ich nicht. Worauf bezieht sich "entsprechend"? Das man /etc/environment _und_ .profile bearbeiten muss.

korrekt, ist so nicht sinnvoll.

Teileweise stehen Befehle in Codeblöcken und Ausgaben in Befehlsboxen.

kann ich mir anschauen

Das Skript unter "Aufruf-Hierarchie anzeigen" sagt, dass jemand da Copyright drauf hat. Mal abgesehen davon, dass ich persönlich das Skript von der Schöpfungshöhe nicht für so genial halte, dass es in irgendeiner Form schützenswert ist: wenn das was geschützt werden soll, sollte der Autor ein Lizenz angeben, unter der das Skript steht.

müssten wir kB fragen, sollte IMHO raus

Ich finde die Trennung im Artikel zwischen "typische Anwendungsfälle" (BTW: wer legt überhaupt fest, was "typisch" ist?) und "weitere Praxisbeispiele" künstlich. IMHO sollte das weg und der ganze Artikel "praktische Anwendungsfälle" oder "praktische Anwendungsbeispiele" heißen.

jupp, ist historisch gewachsen.

Frage: Macht für euch der Artikel / die Auslagerung so Sinn? Dann kann ich das gerne angehen. Zum hinterher löschen ist mir die Zeit mittlerweile zu schade. vgl. 9009783

Gruß BillMaier

Hallo,

Macht für euch der Artikel / die Auslagerung so Sinn?

Ja, finde ich schon. Theorie und Praxis 😉

Gruß, noisefloor

Artikel ist jetzt im Wiki

Hallo,

Der Artikel ist für meinen Geschmack viel zu radikal "gelichtet" worden. Zumindest sollte an den Anfang des Abschnittes "PATH erweitern" noch der folgende Satz aus revision/959636/ zur Erklärung der UV PATH hinein:

Die Umgebungsvariable PATH gibt die Verzeichnisse an, die bei einem Programmaufruf nach dem entsprechenden Programm durchsucht werden; dabei werden die einzelnen Verzeichnisse voneinander durch Doppelpunkt getrennt. Soll z.B. /usr/local/progdir zusätzlich in den Suchpfad aufgenommen werden, lässt sich dies in einer Shell durch einen der folgenden Befehle bewerkstelligen:

BillMaier schrieb:

Hallo,

noisefloor schrieb:

Hallo, (...) Den Satz "Um PATH dauerhaft und systemweit zu erweitern, muss die Datei /etc/environment editiert werden. Entsprechend muss benutzerspezifisch die Datei ~/.profile bearbeitet werden." verstehe ich nicht. Worauf bezieht sich "entsprechend"? Das man /etc/environment _und_ .profile bearbeiten muss.

korrekt, ist so nicht sinnvoll.

Da liegt wohl ein Missverständnis vor! Es geht beim "entsprechend" nicht darum, dass man /etc/environment _und_ ~/.profile bearbeiten muss, sondern darum, dass für alle Benutzer – also "systemweit" – die Datei /etc/environment editiert werden muss und demgegenüber für den aktuell angemeldeten Benutzer – also "benutzerspezifisch" – eben die Datei ~/.profile!

Unter Bezugnahme auf 8935759 möchte ich hiermit außerdem vorschlagen, den Abschnitt "PATH erweitern" ungefähr folgendermaßen zu ergänzen:

PATH um Verzeichnis ~/.local/bin (für pip etc.) erweitern¶

In der benutzerspezifischen Datei ~/.profile steht am Ende bereits vorinstalliert ein Shell-Konstrukt, welches prüft, ob das Verzeichnis $HOME/bin überhaupt existiert. Falls ja, dann wird der existierenden Variable PATH am Anfang ein weiterer Suchpfad /home/<Benutzerkürzel>/bin (durch einen Doppelpunkt getrennt) vorangestellt, wobei <Benutzerkürzel> für den jeweiligen Benutzer-Kurznamen steht.

Im folgenden Beispiel wird diesem Shell-Konstrukt ein entsprechendes für das Verzeichnis ~/.local/bin (bzw. $HOME/.local/bin) vorangestellt (siehe auch pip), so dass in der Datei ~/.profile am Ende dann Folgendes steht:

# setze PATH so, dass es das benutzerspezifische Verzeichnis "$HOME/.local/bin" einschließt, sofern dieses existiert
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Falls nun beide entsprechenden Verzeichnissen existieren würden, so würde die Ausgabe von echo $PATH am Anfang lauten:

/home/<Benutzerkürzel>/bin:/home/<Benutzerkürzel>/.local/bin:

Falls aber eine von beiden oder beide Verzeichnissen nicht existieren würden, so würde(n) der/die entsprechende(n) Suchpfad(e) dort auch nicht auftauchen!

Was meint Ihr zu meinen Vorschlägen?

Hallo,

Was meint Ihr zu meinen Vorschlägen?

Der Artikel war ja echt lange in der Baustelle... aber nun gut.

Ich halte die Ergänzung an dieser Stelle für unpassend. Weil: es heißt "typische" Anwendungsfälle, du erklärst im 1. Abschnitt im weiteren Sinne Grundlagen. Und auch das erweitern der automatischen Prüfung und ggf. Erweiterung des Suchpfads ist kein "typischer Anwendungsfall".

Wenn ist zumindest der Grundlagenteil was für Baustelle/Umgebungsvariable. Der Artikel ist ja passender Weise auch noch in der Überarbeitung.

BTW: was die "Shell-Konstrukt" nennst, wird landläufig als "Shell-Skript" bezeichnet...

Gru0, noisefloor

Hallo,

noisefloor schrieb:

Hallo,

Was meint Ihr zu meinen Vorschlägen?

Der Artikel war ja echt lange in der Baustelle... aber nun gut.

Richtig, aber ich wollte zunächst dessen Fertigstellung und Diskussion durch andere Bearbeiter abwarten, es ging bei letzterer für meinen Geschmack ja oft ziemlich konfus zu...

Ich halte die Ergänzung an dieser Stelle für unpassend. Weil: es heißt "typische" Anwendungsfälle, du erklärst im 1. Abschnitt im weiteren Sinne Grundlagen. Und auch das erweitern der automatischen Prüfung und ggf. Erweiterung des Suchpfads ist kein "typischer Anwendungsfall".

Dann beantworte mir doch bitte die folgenden 3 Fragen bzw. kommentiere bitte meine etwaige Meinung dazu:
1) Wenn das Erweitern der automatischen Prüfung und ggf. Erweiterung des Suchpfads ist kein "typischer Anwendungsfall" ist, was ist es denn dann, bzw. müsste man dann nicht den Abschnitt "PATH erweitern" entfernen?
2) Im pip-Artikel steht im Abschnitt "Wohin werden mit pip installierte Python-Module installiert?" folgender Hinweis:

Hinweis:

~/.local/bin ist standardmäßig nicht im Suchpfad für ausführbare Programm enthalten, man muss das Verzeichnis den Umgebungsvariablen hinzufügen.

In Umgebungsvariablen findet man aber lediglich im Abschnitt "Dauerhafte Änderungen" Links auf Umgebungsvariable/Dateien bzw. Umgebungsvariable/typische Anwendungsfälle (wobei letzterer ja in der Baustelle fehlt). Frage: Wie soll denn Bitteschön damit jemand auf ~/.local/bin kommen, das ist doch für jemand, der sich in der Thematik nicht auskennt, alles viel zu kompliziert, er oder sie wird so zu keiner brauchbaren Lösung kommen können! Falls in den 3 Umgebungsvariablen-Artikeln kein Hinweis auf ~/.local/bin auftauchen darf, dann sollte IMHO einer direkt in den pip-Artikel platziert werden!
3) Wenn im Abschnitt "PATH erweitern" etwas von der systemweiten Editierung der Datei /etc/environment die Rede ist, müsste dann nicht folgerichtig im Gegenzug nicht auch etwas über die benutzerspezifische Editierung der Datei ~/.local/bin geschrieben werden?

Wenn ist zumindest der Grundlagenteil was für Baustelle/Umgebungsvariable. Der Artikel ist ja passender Weise auch noch in der Überarbeitung.

Richtig, ich habe mir das soeben angesehen, da steht ja auch schon was über PATH, was für mich auch so vollkommen ausreichend wäre...

BTW: was die "Shell-Konstrukt" nennst, wird landläufig als "Shell-Skript" bezeichnet...

Ein eingebettetes Skript sozusagen, eingebettet in eine Konfigurationsdatei. Ich habe bisher halt gedacht, dass man soetwas als "Shell-Konstrukt in Skript-Syntax" bezeichnen könnte...

Gru0, noisefloor

linux_joy schrieb:

[…] Ein eingebettetes Skript sozusagen, eingebettet in eine Konfigurationsdatei.

Nein. Die Datei ~/.profile ist ein Shell-Skript und wird auch als solches von dem Programm ausgeführt, welches als Login-Shell verwendet wird. Das muss nicht immer die konkrete Shell bash sein, aber häufig ist sie es, jedenfalls für normale Benutzer. Die Datei ~/.profile enthält daher POSIX-Shell kompatible Befehle; diese kannst Du gerne „Konstrukte“ nennen.

Übrigens enthält, jedenfalls unter Ubuntu 18.04, die mitgelieferte Datei ~/.profile bereits ein Konstrukt zur Einbindung des Verzeichnisses ~/.local/bin/ in den benutzerspezifischen Suchpfad (die Umgebungsvariable PFAD für alle vom Benutzer gestarteten Programme). Deshalb ist das von Dir vorgeschlagene Beispiel eben keine typische Anwendung für das Thema Umgebungsvariable, sondern schlicht überflüssig.

Hallo,

kB schrieb:

linux_joy schrieb:

[…] Ein eingebettetes Skript sozusagen, eingebettet in eine Konfigurationsdatei.

Nein. Die Datei ~/.profile ist ein Shell-Skript und wird auch als solches von dem Programm ausgeführt, welches als Login-Shell verwendet wird. Das muss nicht immer die konkrete Shell bash sein, aber häufig ist sie es, jedenfalls für normale Benutzer. Die Datei ~/.profile enthält daher POSIX-Shell kompatible Befehle; diese kannst Du gerne „Konstrukte“ nennen.

OK

Übrigens enthält, jedenfalls unter Ubuntu 18.04, die mitgelieferte Datei ~/.profile bereits ein Konstrukt zur Einbindung des Verzeichnisses ~/.local/bin/ in den benutzerspezifischen Suchpfad (die Umgebungsvariable PFAD für alle vom Benutzer gestarteten Programme). Deshalb ist das von Dir vorgeschlagene Beispiel eben keine typische Anwendung für das Thema Umgebungsvariable, sondern schlicht überflüssig.

Ich habe darüber mal eine Internet-Suchmaschine bemüht und ganz oben den folgenden Link erhalten: https://unix.stackexchange.com/questions/316765/which-distributions-have-home-local-bin-in-path . Dort werden auch 2 Bug-Reports erwähnt, in welchen ausgegührt wird (v.a. im 2ten), dass auch in manchen neueren Ubuntu-Versionen (z.B. Ubuntu MATE 18.04 LTS) ~/.local/bin/ immer noch nicht im PATH ist. Also doch nicht ganz überflüssig, sondern beispielsweise was für einen zu schaffenden Abschnitt "Problembehebung" oder/und den Artikel pip!

Hallo,

oder/und den Artikel pip!

Das ganz sich nicht, weil das nicht Gegenstand des Artikels zu pip ist. Ja, es kann vorkommen, dass via pip installierte Module etwas nach ~/.local/bin kopieren, aber grundsätzlich ist das Verzeichnis ja in keinster Weise spezifisch für pip.

(z.B. Ubuntu MATE 18.04 LTS)

Das ist bereits EOL, also nicht mehr relevant für's Wiki.

sondern beispielsweise was für einen zu schaffenden Abschnitt "Problembehebung"

Wieso Problembehebung? Das passt doch nicht.

Gruß, noisefloor

noisefloor schrieb:

[…]

(z.B. Ubuntu MATE 18.04 LTS)

Das ist bereits EOL

Das überrascht mich, und

https://help.ubuntu.com/community/EOL

ist anderer Meinung: Ubuntu MATE 16.04 ist EOL und auch Ubuntu Studio 18.04, welches in der Tabelle eine Zeile tiefer steht, aber Ubuntu MATE 18.04 wird noch bis 2021-04 gepflegt.

Wenn sich das aktuelle Ubuntu MATE 18.04 LTS bzgl. der Addition eines existierenden Verzeichnisses ~/.local/bin zur Variablen PATH anders verhält als andere Varianten von Ubuntu, wäre das ein Bug bei MATE. Wahrscheinlicher erscheint mir jedoch dieser Aspekt: Der Einbau des zusätzlichen Verzeichnisses erfolgt ja normalerweise über die benutzerspezifische Datei ~/.profile, welche bei der Geburt des Benutzers als Kopie von /etc/skel/.profile angelegt wird und danach nicht bei einem System-Update angepasst wird. Die automatische Fehlerbeseitigung erfolgt also nur bis zur Datei /etc/skel/.profile. Benutzer, die schon existierten, bevor der Bug beseitigt wurde, müssen in der Tat selber Hand an ihre Datei ~/.profile anlegen. Dieser Aspekt hat aber eigentlich nichts direkt mit Umgebungsvariablen zu tun, sondern betrifft die Initialisierung einer Login-Shell.

Hallo,

kB schrieb:

Das überrascht mich, und

Stimmt, Fehler meinerseits. Die offiziellen Derivate von 18.04 sind nicht EOL.

Gruß, noisefloor

Hi,

Dieser frühe Abschnitt:

human-readable BLOCK_SIZE¶

Viele GNU-Programme (df, du, ls usw.) zeigen Größen in "blocks" an. Diese Anzeige, der block-Größe, kann man so abändern, das sie leichter zu lesen ist.

1 2	> BLOCK_SIZE=human-readable >

Das Vererben (export) dieser Variable ist jedoch nicht ratsam, damit die Ausgabe in Shell-Skripten etc. weiterhin stimmt.

macht mich etwas ratlos - leichter zu lesen, wegen größerer Schrift bestimmt nicht, andere Glyphen erst recht nicht, aber was dann?

Blockgröße und Shellskripte im dt. zusammen, ein Wort und als Substantiv im Ganzen groß.

"Größen in "blocks" an" vielleicht zu "Größen in blocks an" ändern - ist ja nur ein Fachausdruck, keine direkte Rede und kein Zitat.

Desweiteren irritierte mich mehrfach gleich im nächsten Abschnitt:

Im folgenden Beispiel wird ein einzelnes Programm explizit mit einer anderen als der Systemsprache gestartet (hier in Englisch), gilt ab Ubuntu 14.04:

1	LANGUAGE=de PROGRAMM

Für deutsche Schrift innerhalb eines Programms.

Erst dachte ich ein Fehler beim Hin-und-Herändern, letztlich doch bei hier-in-Deutsch geendet, bis ich endlich zu verstehen meinte, dass die Systemsprache hier Englisch ist. Ist die woanders anders? Was ist denn eine Systemsprache? Ah - gemeint ist, dass im Environment Englisch vorgegeben ist (könnte aber auch Französisch sein; default ist ja schon Englisch) und da kann man jetzt so ein Programm trotzdem mit anderer Sprache (Sprache, nicht Schrift!) starten.

Ja, wobei ganz pingelige noch anmerken könnten, dass das selbst dann PROGRAMM in deutsch startet, wenn die Umgebungsvariable sowieso schon auf Deutsch gesetzt ist.

Langer Rede kurzer Sinn; Vorschlag:

Unabhängig von den systemweiten und benutzerspezifischen Einstellungen startet man eine Anweisung mit deutscher Sprache (wenn das Kommando/Programm das unterstützt) mit

1	LANGUAGE=de PROGRAMM

(gilt seit Ubuntu 14.04)

Seit statt ab, denn Leute die heute erst planen in Zukunft dann mal 14.04 zu installieren wollen wir nicht gezielt ansprechen.

Hallo zusammen,

um nicht zuletzt auch 9081971 wieder aufzugreifen, aber dabei aufs wesentliche zu reduzieren, kommt hier mein folgender Vorschlag:

PATH erweitern¶

wird erweitert zu:

PATH erweitern¶

Nur für die aktuelle Sitzung und auch nur in der aktuellen Shell:

PATH=$PATH:/usr/local/progdir   # neues Verzeichnis zuletzt durchsuchen
PATH="/usr/local/progdir:$PATH" # neues Verzeichnis zuerst durchsuchen 

Um PATH dauerhaft und systemweit zu erweitern, muss die Datei /etc/environment editiert werden. Seit Ubuntu 17.10 geht das auch über /etc/environment.d/*.conf, was den Vorteil hat, dass die Originaleinstellung erhalten bleibt, und die individuelle Erweiterung schnell (auch temporär) deaktiviert werden kann.

Um dagegen PATH dauerhaft und für den aktuellen Benutzer zu erweitern, muss die Datei ~/.profile bearbeitet werden.

Der jeweils erste und letzte Satz kommt also hinzu.

Hallo,

ist denke ich ok.

Gruß, noisefloor