staging.inyokaproject.org

kB schrieb:

• Ihr habt gelesen, was ich schrieb?

Ja, sonderlich viel und gar begründet war es ja nicht. Dieses "ihr habt gelesen" ist auch nicht besonders sachlich, und wichtiger / richtiger wird es auch nicht, wenn man -999 schreibt. Sorry, das ist kindisch. Aber es ist doch ganz einfach: du hast keine Traute, dann lass es, wir finden es für uns gut und können es überschauen, also manchen wir es, soweit wir es für richtig halten. So einfach.

+1000 daher für Meier's Willhelm

Seebär schrieb:

du hast keine Traute, dann lass es

na, jetzt aber mal halblang. Ich wollte Mitstreiter für diesen Artikel, nicht Gegeneinander-Streiter. (wenn dann bitte nur auf sachlicher Ebene - und da soll bitte jeder auf seine eigene Nase achten. Ich auf meine)

Zum Thema PAM nochmal: Hier wird sogar die pam-Einstellung geändert. Wuah, das würde ich aber wirklich nicht machen wollen: https://askubuntu.com/questions/866161/setting-path-variable-in-etc-environment-vs-profile

Und wer weiß jetzt was zu systemd? Außer dass man die Variablen im systemd-service-File mit gibt (was ja wiederum nicht global ist)

Hallo,

ich habe vorhin mal den Abschn. PATH erweitern so bearbeitet, dass dort jetzt am Ende zusätzlich der Satz "Entsprechend muss benutzerspezifisch die Datei ~/.profile bearbeitet werden." steht. Das ist im Prinzip zwar richtig, jedoch steht dort z.B. bei Ubuntu 14.04 folgendes (am Ende):

1
2
3
4

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

Da fehlt am Ende also das export PATH (Die Datei ist original).

Auf diesen Umstand müsste im Artikel meiner Meinung nach hingewiesen werden, am Besten aber verweise man auf das von mir zitierte Beispiel, denn dort ist ja auch noch eine Abfrage, ob das Verzeichnis $HOME/bin denn überhaupt existiert. ⇒⇒⇒ Wäre es denn überhaupt schädlich, falls die PATH-Variable bei nicht-existierendem Verzeichnis $HOME/bin erweitert würde?

Nur zum Vergleich: Was steht denn Entsprechendes standardmäßig in ~/.profile bei Ubuntu 16.04? Steht da vor dem bin evtl. noch ein .?

Außerdem zum Vergleich: Bei LMDE2 ist /etc/environment komplett leer, in /etc/profile steht am Anfang:

1
2
3
4
5
6

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

Also MIT export PATH. Und in ~/.profile steht bei LMDE2 am Ende exakt dasselbe wie bei 14.04, also OHNE export PATH. Wird das export PATH also anscheinend nur bei den systemweiten Dateien benötigt?

Hallo linux_joy schrieb:

Hallo,

ich habe vorhin mal den Abschn. PATH erweitern so bearbeitet, dass dort jetzt am Ende zusätzlich der Satz "Entsprechend muss benutzerspezifisch die Datei ~/.profile bearbeitet werden." steht. Das ist im Prinzip zwar richtig, jedoch steht dort z.B. bei Ubuntu 14.04 folgendes (am Ende):

1 2 3 4

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

Da fehlt am Ende also das export PATH (Die Datei ist original).

das genauso bei /etc/environment nicht benötigt wird. Wie also würdest du den Artikel hier dann ändern wollen?

Wäre es denn überhaupt schädlich, falls die PATH-Variable bei nicht-existierendem Verzeichnis $HOME/bin erweitert würde?

Es wäre zumindest unsauber. Ob es weiter ganz schlimme Auswirkungen hat, weiß ich nicht. Kannst ja mal probieren, die PATH-Variable um ein nicht existentes (anderes) Verzeichnis zu erweitern, wenn du es genau wissen willst. Aber warum stellst du hier den Sinn und Zweck einer Systemeinstellung in Ubuntu in Frage?

Nur zum Vergleich: Was steht denn Entsprechendes standardmäßig in ~/.profile bei Ubuntu 16.04? Steht da vor dem bin evtl. noch ein .?

Unter 17.10 jedenfalls nicht. Warum sollte?

Wird das export PATH also anscheinend nur bei den systemweiten Dateien benötigt?

Hmm, nicht mal da wird es konsequent gemacht:

cat /etc/profile.d/apps-bin-path.sh 
# Expand the $PATH to include /snap/bin which is what snappy applications
# use
PATH=$PATH:/snap/bin

Hallo,

ich möchte Euch hiermit vielmals um Entschuldigung bitten, weil ich erst nach sooo laanger Zeit antworte 😳

BillMaier schrieb:

Hallo linux_joy schrieb:

Hallo,

ich habe vorhin mal den Abschn. PATH erweitern so bearbeitet, dass dort jetzt am Ende zusätzlich der Satz "Entsprechend muss benutzerspezifisch die Datei ~/.profile bearbeitet werden." steht. Das ist im Prinzip zwar richtig, jedoch steht dort z.B. bei Ubuntu 14.04 folgendes (am Ende):

1 2 3 4

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

Da fehlt am Ende also das export PATH (Die Datei ist original).

das genauso bei /etc/environment nicht benötigt wird.

Ja, aber selbstverständlich _nicht_:

Login über Textkonsole¶

(...)

Alternativ kann man Variablen in der Datei /etc/environment eintragen. Diese Datei wird nicht von der Shell, sondern von pam_env ausgewertet. Man kann dort daher keine Shell-Syntax verwenden, sondern nur einfache Zeilen der Art

VARIABLE=Wert-der-Variable

wobei Wert-der-Variable genau so übernommen wird, wie es dasteht, also mit Anführungszeichen, $ usw. Auch die Verwendung von export ist nicht erlaubt. Änderungen in /etc/environment werden erst nach einer erneuten Anmeldung übernommen.

(Die Unterstreichung des Satzes stammt von mir.)

Wie also würdest du den Artikel hier dann ändern wollen?

Zunächst Artikel-Zitat:

Dauerhafte Änderungen¶

Wie gesagt gelten solche Variablen nur für die aktuelle Sitzung. Variablen lassen sich jedoch auch dauerhaft definieren.

Hinweis:

Die Variablen müssen in den Dateien auch mit dem Befehl export definiert werden.

Zum einen:
Die Hinweis-Box müsste entweder ganz verschwinden oder aber um variablen- bzw. shell-spezifische ("login- und non-login-shell...") Besonderheiten ergänzt werden.

Zum anderen:

PATH erweitern¶

Am Ende wird Folgendes angefügt:

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 $HOME/.local/bin vorangestellt (siehe auch pip), so dass in der Datei ~/.profile am Ende dann Folgendes steht:

# set PATH so it includes user's .local/bin if it exists
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!

Hinweis:

• Der export-Befehl ist in diesem Fall nicht nötig.

• Falls man in diesem Fall den source ~/.profile-Befehl verwenden würde, so würde das Verzeichnis $HOME/bin doppelt in PATH auftauchen. Also sich lieber ab- und gleich danach wieder anmelden.

Dazu fällt mir Folgendes auf:

Änderung für einen Benutzer¶

(...)

Die Änderungen in der Datei ~/.profile können ohne Neustart der Bash durch folgenden Befehl übernommen werden:

source ~/.profile 

Sollte es stattdessen nicht heißen:

"Die Änderungen in der Datei ~/.profile können ohne Benutzer-Ab- sowie erneute -Anmeldung durch folgenden Befehl übernommen werden:" ???

Wäre es denn überhaupt schädlich, falls die PATH-Variable bei nicht-existierendem Verzeichnis $HOME/bin erweitert würde?

Es wäre zumindest unsauber. Ob es weiter ganz schlimme Auswirkungen hat, weiß ich nicht. Kannst ja mal probieren, die PATH-Variable um ein nicht existentes (anderes) Verzeichnis zu erweitern, wenn du es genau wissen willst. Aber warum stellst du hier den Sinn und Zweck einer Systemeinstellung in Ubuntu in Frage?

Es scheint ja _nicht_ schädlich zu sein, denn die PATH-Variable würde ja bei nicht-existierendem Verzeichnis $HOME/bin durch die Shell-Abfrage ganz einfach auch _nicht_ erweitert!

Nur zum Vergleich: Was steht denn Entsprechendes standardmäßig in ~/.profile bei Ubuntu 16.04? Steht da vor dem bin evtl. noch ein .?

Unter 17.10 jedenfalls nicht. Warum sollte?

Ich habe einmal in einem jüngeren Forums-Thread davon gelesen, dass ein Fragesteller, weil er das Verzeichnis $HOME/bin partout nicht zur Variable PATH dazubekommen konnte, stattdessen einfach die Datei ~/.bashrc editiert hat. Daher meine Vermutung. Aber vllt. hatte er lediglich einen Neustart der Bash anstatt einer Benutzer-Ab- sowie erneuten -Anmeldung vorgenommen; siehe oben!

Wird das export PATH also anscheinend nur bei den systemweiten Dateien benötigt?

Hmm, nicht mal da wird es konsequent gemacht:

cat /etc/profile.d/apps-bin-path.sh 
# Expand the $PATH to include /snap/bin which is what snappy applications
# use
PATH=$PATH:/snap/bin

Vllt. hat das ja auch zu tun mit: kB schrieb: (...)

• Welche Dateien bein Start einer (Bourne-like-) Shell berücksichtig werden, hängt von der Art des Aufrufs ab. Man unterscheidet login- und non-login-shell sowie interactive- und non-interactive-shell. Das ist leider eine ziemlich unübersichtliche Angelegenheit. Man sollte daher besser nur die benutzer-spezifischen Dateien unter /home/USER/ anpassen.

Die Sache mit "login- und non-login-shell sowie interactive- und non-interactive-shell" sollte aber auf jeden Fall irgendwo im Wiki genauer erklärt werden; egal ob in diesem Artikel oder z.B. in Shell, Shell/Einführung, Bash oder Bash/bashrc!

Der Wert der Shell-Variable PATH wird von der Shell automatisch in eine existierende gleichnamige Umgebungsvariable geschrieben. Eines export-Befehls bedarf es dazu nicht. Ich habe den Artikel entsprechend überarbeitet.

Der Artikel strotzt übrigens vor Ungenauigkeiten und Fehlern, insbesondere werden mehrfach Umgebungsvariablen und Shell-Variablen miteinander verwechselt oder fälschlicherweise gleichgesetzt. Beispielsweise definieren /etc/profile und auch die anderen Initialisierungsdateien der bash überhaupt keine Umgebungsvariablen, sondern Shell-Variablen für die Shell, welche diese Dateien auswertet. Auswirkungen auf die Umgebung (nur!) dieser konkreten Instanz einer Shell ergeben sich nur durch den o.g. Effekt.

Hallo,

Der Artikel strotzt übrigens vor Ungenauigkeiten und Fehlern

@kB: Wenn du die Fehler schon alle lokalisiert hast wäre es sehr schön, wenn du die direkt korrigieren würdest. Falls du es nicht "on the fly" machen möchtest auch gerne in der Baustelle, die wir dann einrichten.

Gruß, noisefloor

noisefloor schrieb:

[…] Fehler […] korrigieren […] Baustelle […] einrichten

Genau. Bitte Baustelle einrichten!

Hallo,

Baustelle ist eingerichtet.

Gruß, noisefloor

Ich möchte jetzt gerne die Diskussion zum überarbeiteten Artikel mit zahlreichen neuen Informationen eröffnen. Der Text enthält noch einige offensichtliche Bearbeitungsvermerke, die natürlich in der in der endgültigen Fassung von mir entfernt werden und auch das Quellenverzeichnis ist noch nicht endgültig.

Es mag zu diesem Thema noch einige weitere, von mir übersehene besondere Dateien geben. Diese bitte ich um Entschuldigung für ihre Missachtung durch mich, aber ich glaube, alle üblichen Verdächtigen mit allen ihren Schrullen aufgeführt zu haben.

Konstruktive Kritik ist ausdrücklich erwünscht!

Hallo,

ich glaube, ich habe das noch nie gesagt, aber hier ist es IMHO so: das ist durch die Überarbeitung ziemlich unübersichtlich, viel zu lang und damit weniger gut geworden.

Das ganze liest sich eher wie eine Abhandlung mit Anspruch auf allumfassende inhaltliche Abdeckung als ein praxisnaher Wikiartikel für den "täglichen" Umgang mit Umgebungsvariablen.

Formelle Sachen:

• Datei- und Verzeichnisnamen immer fett

• Tabellen werden nicht nummeriert

• Abkürzungstabellen verwenden wir nicht. Entweder verwendet man allgemein bekannte Abkürzungen wie "z.B." oder "i.d.R" oder man schreibt es durchgehend aus. Besonders UV darfst du bitte durchgehend ausschreiben.

• Die Tabellen 1 und 2 sind IMHO hochgradig unübersichtlich. Einmal wegen den kryptischen Abkürzungen zum anderen wegen der Größe (=Spalten- und Zeilenanzahl). Da besteht Nachbesserungsbedarf zur Verbesserung der Übersichtlichkeit

• Die Tabelle "Man lese je nach Situation weiter" darf auch weg. Es bleibt dem Leser überlassen, was er liest. Zumal die folgenden Überschriften ja eindeutig sind.

• "und auch das Quellenverzeichnis ist noch nicht endgültig." - es ist ein Wiki (und nicht das von Wikipedia) und keine wissenschaftliche Abhandlung → wir brauchen (und wollen) keine Quellenangaben. Wenn dann hilfreiche, weiterführende Links.

• keine direkten Anreden bzw. Worte wie "ich"

Ggf. würde es hier auch helfen, den Artikel zu unterteilen, z.B. in einen für das Systems und einen für interaktive Shells.

Gruß, noisefloor

Hallo,

habe die Baustelle gerade nochmal gelesen. Ganz ehrlich: ich halten den Artikel in der aktuellen Form für ungeeignet für das Wiki hier.

In Teilen zu akademisch, zu viele Abschweifungen zu anderen Themen (wie Unterschiede Bash und Dash oder das Setzen von Variablen für systemd), zu viele für das "tägliche Arbeiten" irrelevante Info (muss man wissen, was warum durch ein NUL-Byte terminiert wird? Nee, muss man nicht).

IMHO sollte / müsste der Artikel im größeren Maßstab überarbeitet werden, um eine brauchbare praxistauglichkeit für interessierte Leser zu haben.

Es ist zwar Schade um die ganze Arbeit / Zeit, aber aus der Frage nach Überarbeitung in 8935809 ging nicht hervor, dass das auf eine Verdopplung der Länge des Artikels und einem 90%igen Rewrite hinausläuft. Sonst hätten wir das vorher schon in einen passendere Bahn gelenkt.

Gruß, noisefloor

Hi!

Dieser Einschub (der zudem nichts in einem Wiki-Artikel zu suchen hat) bringt es auf den Punkt:

(Ich bewundere Leute, die diesen Satz auf Anhieb verstehen!)

und das gilt für mich den ganzen Artikel 😲

Ich kann noisefloor nur zustimmen. Auch ich halte den Artikel in dieser Form ungeeignet fürs Wiki.

so long
hank

Die Thematik „Umgebungsvariable“ ist kompliziert, weil – wie in der Baustelle dargestellt – viele verschiedene Komponenten hier mitmischen. Eine halbwegs zutreffende Darstellung wird zwangsläufig umfangreich sein, selbst wenn man sich auf die aktuellen Ubuntu-Versionen beschränkt.

Andererseits wimmelt das Internet von Supportanfragen bezüglich Umgebungsvariablen, die nicht wie erwartet funktionieren. Dabei sind oft erkennbare Fehlerquellen:

1. Man verwendet eine ungeeignete Konfigurations- bzw. Initialisierungsdatei, z.B. eine solche, die in der jeweiligen Situation gar nicht ausgewertet wird, weil:

   1. System-Modus und User-Modus verwechselt wird

   2. die unterschiedliche Behandlung der Konfigurations- bzw. Initialisierungsdateien in den möglichen Aufrufarten eines Kommando-Interpreters (Login-Shell, interaktive Shell, GUI) nicht bewusst ist

   3. es wird eine bestimmte Shell, meist die Bash, vorausgesetzt, das Skript wird aber von der Dash ausgeführt

   4. durch eine an unpassender Stell tatsächlich gesetzte Umgebungsvariablen wird die korrekte Funktion eines Programms gestört

2. Man verwendet eine falsche Syntax.

Diese Supportanfragen werden oft mit gut gemeinten geratenen, aber untauglichen Hinweisen beantwortet. Das führt typischerweise zu einem Ausprobieren aller möglichen Konfigurations- bzw. Initialisierungsdateien, die mangels Wissen dann zerstört werden und im Extrem in einem unbenutzbaren System endet.

Eine systematische und richtige Darstellung der Thematik habe ich im Internet nicht gefunden.

Mein Anliegen war daher, wenigstens für den Kernbereich von UU.de die Verhältnisse grundlegend zu beschreiben. Ich habe mich dabei um Kürze und leichte Verständlichkeit, aber auch um angemessene Vollständigkeit bemüht – vom Ergebnis her sehe ich aber mein Werk auch als zu komplex und zu lang.

Ich bin gerne bereit, den Vorschlag zur von noisefloor zur Aufteilung des Themas auf mehrere Seiten aufzugreifen und auch die formalen Mängel werden natürlich behoben. Der summierte Umfang dieser Seiten wird aber dabei nicht kleiner werden und wenigstens einige dieser Unterseiten würden kompliziert bleiben, weil die Thematik an sich kompliziert ist. Wie eine solche Aufteilung aussehen könnte, darüber müsste ich noch nachdenken bzw. würde auch gerne Eure Vorschläge berücksichtigen.

Andererseits kann ich mir auch vorstellen, den Text aus UU.de komplett zurückzuziehen. Genau wegen dieser Option habe ich ja eine Baustelle einrichten lassen.

Hallo,

Wie eine solche Aufteilung aussehen könnte, darüber müsste ich noch nachdenken bzw. würde auch gerne Eure Vorschläge berücksichtigen.

Thematisch logisch-zusammenhängende Blöcke ist immer sinnvoll.

Also zumindest mal Bootvorgang und "Rest". Ob man erst noch in Login-Shell und "textbasierte" Shell unterteilt kann ich nicht beurteilen, dazu durchblicke ich den Artikel aktuell nicht genug.

Ein Vorschlag deinerseits ist gerne willkommen ☺

Wenn der Artikel beim Supporten helfen soll - was ja durchaus Sinn von Wikiartikel ist - dann muss es 1. besser lesbar sein (geht i.d.R. mit kürzer einher) und 2. mehr "hand-on" (=praxisbezogen) sein. Es ist _nicht_ Sinn eines Wikiartikels, alle Supportanfragen beantworten zu können - würde so wie so nicht funktionieren, weil niemals jeder "corner case" abgedeckt werden kann.

Gruß, noisefloor