staging.inyokaproject.org

... und ich lese deinen zweiten post nach meinem.

user_unknown schrieb:

Muss mir die verlinkten Texte/Beispiele nochmal zu Gemüte führen.

Bitte ☺

BillMaier schrieb:

Hey user_unknown

danke für deine Rückmeldung. Vieles davon ist so alt, dass vermutlich keiner mehr weiß von wem. Das meiste der Überarbeitung ist ja in andere Artikel abgewandert.

Magst du dich hier nochmal dran versuchen? Ein "cleanup" schadet bestimmt nicht.

Also die von mir vorgeschlagen Änderungen führe ich einfach durch. (Überschrift: Regeln statt Konventionen, entsprechende ⇒ Konfigurationsdateien, "Wie gesagt" getilgt.).

Baustelle? 😇

Ohne Baustelle.

Das "abgleichen" lasse ich vorläufig drin, weil ich nicht weiß, wer es mit welcher Idee im Kopf reingemacht hat.

Für ein großes Cleanup fehlt mir die Zeit. Ob man die feinsinnige Unterscheidung der Restriktionen von Environment und was die Shells damit machen überhaupt erwähnen sollte? Man sollte natürlich nichts behaupten, was nicht stimmt, also dass ein Minus im Namen generell verboten ist, wenn es das nicht ist. Andererseits: Wer in unserer Zielgruppe braucht dieses Wissen? Ich erinnere mich nicht, es je gebraucht zu haben.

user_unknown schrieb:

[…] Man sollte natürlich nichts behaupten, was nicht stimmt, also dass ein Minus im Namen generell verboten ist, wenn es das nicht ist.

Umgebungsvariable dürfen im Namen das Minuszeichen enthalten und auch jede Menge anderer sonst in Namen verbotener Zeichen. Sie können sogar mit einem Minuszeichen beginnen. Ebenso sind auch Ziffern als erstes Zeichen im Namen einer Umgebungsvariablen zulässig. Man kann dies leicht nachweisen: Das Programm env konstruiert eine Umgebung und startet ein Programm in dieser Umgebung; printenv zeigt die Umgebungsvariablen eines Programms an:

$ env -i a-b=a-minus-b -c=minus-c 137=eins-drei-sieben  bash
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

$ printenv | grep -e '-.*=' -e '^[0-9]'
137=eins-drei-sieben
a-b=a-minus-b
-c=minus-c

Natürlich sind das alles keine zulässigen Namen für Posix-Shell-Variablen und bash übernimmt daher solche Umgebungsvariablen nicht als eigene Variablen.

Andererseits: Wer in unserer Zielgruppe braucht dieses Wissen? Ich erinnere mich nicht, es je gebraucht zu haben.

Jeder, der mit Umgebungsvariablen arbeitet, kann von diesem Wissen profitieren. Dabei geht es nicht darum, dass man solche Spielchen anwendet, sondern man sollte im Gegenteil klugerweise vermeiden, solche Namen für Umgebungsvariablen zu verwenden. Wegen des dann fehlenden Abgleichs zwischen Umgebungsvariable und programminterner Variable bekommt man sonst irgendwann Schlafstörungen, Haarausfall oder andere Probleme.

Dann sollte man das einfach so schreiben.

Vorschlag: Auflistung der Konventionen. Egänzend eine Hinweisbox mit einem Inhalt in der Art wie:

Auch wenn die Regeln für Umgebungsvariablen nicht so eng sind wie hier vorgegeben, sollte man sich trotzdem an diese Konventionen halten. Ein Grund: Die Shell benutzt die ihr gegebenen Umgebungsvariablen als Shell-Variablen. Für diese gelten aber strengere Regeln. Hält man sich nicht an diese, bekommt man leicht unerwünschte Nebeneffekte - bspw. indem diese Übernahme nur fehlerhaft oder nicht erfolgt.

Ist noch keine Reinschrift, aber so weiß man einigermaßen, was denn mit "Abgleich" gemeint ist. Auf diesen Begriff würde ich glaub ich auch verzichten. Abgleich ist für mich in zwei Richtungen, Übernahme nur in eine.

Gruß BillMaier

Hallo zusammen,

meiner Ansicht nach fehlt in der Einleitung etwas entscheidendes, die Stelle mit meinem Vorschlag habe ich davor und dahinter markiert, und der ergänzende Satz-Vorschlag ist auch markiert:

(...)

Mit dem Kommando echo kann man sich den Variableninhalt ausgeben lassen ^[1]:

echo $VARIABLE 

Wert_der_Variable

Mit printenv kann man alle Variablen auf einmal anzeigen lassen.

–––––––––––––––––––––––––
Damit die Variable zunächst nur in der aktuellen Shell zur Verfügung steht, muss das folgende Befehls-Muster aufgerufen werden:

?????? VARIABLE ????????? 

–––––––––––––––––––––––––

Das Kommando export sorgt dafür, dass die Variable nicht nur in der aktuellen Shell, sondern auch in den von der aktuellen Shell aus aufgerufenen Programmen zur Verfügung steht:

export VARIABLE 

Man kann das alles auch in eine einzige Zeile packen:

export VARIABLE=0815 

Siehe auch den Abschnitt Export von Variablen.

(...)

Als Vorschlag für den oder die einzufügenden Befehl(e) könnte evtl. das Muster aus Umgebungsvariable/typische Anwendungsfälle (Abschnitt „PATH-erweitern“) dienen, oder liege ich damit etwa total daneben?:

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

Zusatz-Frage: Weiß von Euch irgendjemand zufällig, wie sich Befehls-Boxen markieren lassen könnten (um nämlich nicht stattdessen umständlich davor und dahinter markieren zu müssen)?

Hallo,

stimmt, fehlenden Abschnitt eingefügt. Danke für den Hinweis.

Weiß von Euch irgendjemand zufällig, wie sich Befehls-Boxen markieren lassen könnten

Gar nicht? Das ist auch nicht vorgesehen. Wenn du vorher eine Markierung setzt müsst der CSS-Stil von dem CSS-Stil der Befehlsbox überschrieben werden, weshalb das nicht geht.

Gruß, noisefloor

Hallo,

ich verstehe in dem Artikel manches nicht, und möchte dazu anregen, das klarer zu formulieren.

Environment-Variablen werden bei der Prozessgenerierung "vererbt", d.h. ...

Das Kommando export sorgt dafür, dass die Variable nicht nur in der aktuellen Shell, sondern auch in den von der aktuellen Shell aus aufgerufenen Programmen zur Verfügung steht:

Ein Programmaufruf generiert doch immer einen Prozess. Im oberen Zitat steht, dass die Variablen grundsätzlich vererbt werden, im zweiten, dass die Variable dafür exportiert werden muss. Das widerspricht sich nach meinem Verständnis.
Weiterhin fände ich es besser, "Umgebungsvariable" statt "Environment-Variable" zu verwenden.

Das Kommando export ...

Weiter unten:

Die Markierung einer Variablen mit dem Export-Attribut ...

Ist export nun ein Kommando, oder ein Attribut?

Überhaupt fände ich es besser, export erst weiter unten in dem dafür vorgesehenen Abschnitt "Export von Variablen" zu erwähnen.

Für den Namensteil einer Umgebungsvariablen kann man nur druckbare, aber keine regions- oder sprachspezifischen Zeichen verwenden; als Sonderzeichen ist nur der Untertrich zulässig.

Beispielsweise ist zwar „NAME-DER-VARIABLEN“ ein zulässiger Namensteil einer Umgebungsvariable ...

1. Warum "...teil", es geht doch um den ganzen Namen, der höchstens Teil einer Variablen-Definition ist.
2. Im unteren Satz werden '-' verwendet, obwohl doch angeblich nur Unterstriche zulässig sind.

Erst im Abschnitt "Regeln für die Namensgebung" wird nebenbei auf den Unterschied zwischen Shell- und Umgebungsvariable hingewiesen. Sollte das nicht gleich besser am Anfang erklärt werden? Genauso auch, wer wen bei Namensgleichheit überschreibt.

UlfZibis schrieb:

Ein Programmaufruf generiert doch immer einen Prozess. Im oberen Zitat steht, dass die Variablen grundsätzlich vererbt werden, im zweiten, dass die Variable dafür exportiert werden muss. Das widerspricht sich nach meinem Verständnis.

Die Ausführung eines Shell-Builtin erzeugt z.B. keinen extra Prozess, z.B. muss cd vom Shell-Prozess selbst ausgeführt werden, weil Kind-Prozesse nicht das Arbeitsverzeichnis ihrerer Eltern ändern dürfen.

Das Kommando export ...

Weiter unten:

Die Markierung einer Variablen mit dem Export-Attribut ...

Ist export nun ein Kommando, oder ein Attribut?

export ist ein Befehl, der das export-Attribut setzt - vgl. Manpage (https://manpages.ubuntu.com/manpages/bionic/man1/export.1posix.html) - die Implementierung ist Sache der jeweils genutzten Shell.

seahawk1986 schrieb:

Die Ausführung eines Shell-Builtin erzeugt z.B. keinen extra Prozess, z.B. muss cd vom Shell-Prozess selbst ausgeführt werden, weil Kind-Prozesse nicht das Arbeitsverzeichnis ihrerer Eltern ändern dürfen.

Es gibt also noch eine weitere Unterscheidung, deren Bedeutung und Wirkung aus dem Artikel in der jetzigen Form nicht hervorgeht.

Die Markierung einer Variablen mit dem Export-Attribut ...

Ist export nun ein Kommando, oder ein Attribut?

export ist ein Befehl, der das export-Attribut setzt - vgl. Manpage (https://manpages.ubuntu.com/manpages/bionic/man1/export.1posix.html) - die Implementierung ist Sache der jeweils genutzten Shell.

Würde man da nicht besser einfach schreiben:

Der Export einer Variablen ...

... damit der Leser sich nicht auch noch Gedanken um die Implementierung machen muss? Oder weiter oben erklären:

export setzt/markiert das Export-Attribut einer (Shell|Umgebungs)variablen.

Könnte man noch eine Weiterleitung auf PATH anlegen?

Done.

Gruß, noisefloor

Sehr schön, Danke!

Kann mir jemand die Experten-Box am Ende des Artikels erklären?

Ich finde den Inhalt der Box äußerst verwirrend. Das Standardverhalten unter Debian/Ubuntu ist doch, dass die .bashrc von /etc/profile bzw. ~/.profile gesourced wird.

Was ist dann damit gemeint, dass .profile standardmäßig "nicht ausgewertet" wird? Wenn ich in der ~/.profile ein

export FOO=BAR

eintrage, dann kann ich auf die Variable $FOO aus dem GNOME-Terminal standardmäßig sehr wohl zugreifen. Oder sind damit die Einstellungen der Shell, wie z.B. die Gestaltung des Prompts gemeint?

Ich finde es dabei auch unglücklich, dass im ganzen Artikel von Shell die Rede ist und auf einmal von "Terminal" und dann noch "GNOME-Terminal".

Und welchen Vorteil habe ich, wenn ich im Terminal "Befehl als Login-Shell starten" wähle. Werden dann nicht stattdessen die Skripte/Dateien doppelt abgearbeitet, die normalerweise nur beim Login hinsichtlich der Shell ausgeführt würden und zwar dann immer, wenn ich ein neues Terminal öffne?

Für eine genauere Erklärung wäre ich sehr dankbar!

LG, Newubunti

Hallo,

Unterschied zwischen den Shells: Shell/Modi.

Ich finde es dabei auch unglücklich, dass im ganzen Artikel von Shell die Rede ist und auf einmal von "Terminal" und dann noch "GNOME-Terminal".

Aber das ist doch iMHO im Kontext des Artikels richtig. Shell != Terminal, auch wenn im Terminal eine Shell läuft. Aber es gibt ja auch Shells, die _nicht_ im Terminal laufen - siehe Shell/Modi. Das in der Box erst von Terminal und dann von GNOME-Terminal die Rede ist liegt daran, dass doch beschrieben wird, wie man was im GNOME-Terminal ändert. Das kann bei den Terminals der andere DEs vermutlich anders sein.

Gruß, noisefloor

noisefloor schrieb:

Aber das ist doch iMHO im Kontext des Artikels richtig. Shell != Terminal,

Ja schon, aber das Gnome-Terminal wird doch in aller Regel innerhalb/unterhalb einer übergeordneten Umgebung laufen, die in der Standard-Konfig unter Ubuntu sehr wohl die .profile verwendet und dementsprechend die darin definierten Umgebungsvariablen an das Gnome-Terminal vererbt bzw. die darin ausgeführte Shell. Da ist es IMO zunächst mal schlüssig, dass das Gnome-Terminal, die .profile nicht selbst bei Ausführung nochmal anwendet.

Ich finde den Begriff "normal" in der Expertenbox insoweit verwirrend/unglücklich.

Einerseits wird die Verwendung der .bashrc als "unnötig kompliziert" dargestellt, eben mit der Begründung der Umgebungsvererbung andererseits fällt unter den Tisch, dass das Gnome-Terminal die Nutzerumgebung aus der .profile auch schon geerbt hat.

Oder verstehe ich etwas falsch (was durchaus möglich ist)?

LG, Newubunti