... und ich lese deinen zweiten post nach meinem.
Muss mir die verlinkten Texte/Beispiele nochmal zu Gemüte führen.
Bitte ☺
Supporter
Anmeldungsdatum: Beiträge: 6389 |
... und ich lese deinen zweiten post nach meinem.
Bitte ☺ |
Anmeldungsdatum: Beiträge: 17432 |
Also die von mir vorgeschlagen Änderungen führe ich einfach durch. (Überschrift: Regeln statt Konventionen, entsprechende ⇒ Konfigurationsdateien, "Wie gesagt" getilgt.).
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. |
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 7816 |
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.
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. |
Supporter
Anmeldungsdatum: Beiträge: 6389 |
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 |
Anmeldungsdatum: Beiträge: 636 |
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:
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?:
|
Ehemaliger
Anmeldungsdatum: Beiträge: 28316 |
Hallo, stimmt, fehlenden Abschnitt eingefügt. Danke für den Hinweis.
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 |
Anmeldungsdatum: Beiträge: 2726 |
Hallo, ich verstehe in dem Artikel manches nicht, und möchte dazu anregen, das klarer zu formulieren.
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.
Weiter unten:
Ist Überhaupt fände ich es besser,
1. Warum "...teil", es geht doch um den ganzen Namen, der höchstens Teil einer Variablen-Definition ist. 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. |
Anmeldungsdatum: Beiträge: 10978 |
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.
|
Anmeldungsdatum: Beiträge: 2726 |
Es gibt also noch eine weitere Unterscheidung, deren Bedeutung und Wirkung aus dem Artikel in der jetzigen Form nicht hervorgeht.
Würde man da nicht besser einfach schreiben:
... damit der Leser sich nicht auch noch Gedanken um die Implementierung machen muss? Oder weiter oben erklären:
|
Supporter
Anmeldungsdatum: Beiträge: 52312 |
Könnte man noch eine Weiterleitung auf PATH anlegen? |
Ehemaliger
Anmeldungsdatum: Beiträge: 28316 |
Done. Gruß, noisefloor |
Supporter
Anmeldungsdatum: Beiträge: 52312 |
Sehr schön, Danke! |
Anmeldungsdatum: Beiträge: 4768 |
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 |
Ehemaliger
Anmeldungsdatum: Beiträge: 28316 |
Hallo, Unterschied zwischen den Shells: Shell/Modi.
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 |
Anmeldungsdatum: Beiträge: 4768 |
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 |