staging.inyokaproject.org

Hallo,

Hinweis für die weitere Bearbeitung: was im Abschnitt "UV für den Linux-Kernel" steht ist IMHO redundant mit Bootoptionen.

Ansonsten finde ich die aktuelle Strukturierung ganz gut.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

Hinweis für die weitere Bearbeitung: was im Abschnitt "UV für den Linux-Kernel" steht ist IMHO redundant mit Bootoptionen.

Guter Hinweis, danke.

Ansonsten finde ich die aktuelle Strukturierung ganz gut.

schön.

Hallo,

um den Artikel strukturiert Richtung Wiki zu bringen, benötige ich nochmal inhaltliche Unterstützung: Ich habe dazu zwei TODO-Blöcke (direkt in den Artikel, ohne Kommentar) eingefügt - da weist der Artikel IMHO Widersprüche auf.

Das dritte TODO (Todo BillMaier richtet sich natürlich an mich, kann also ignoriert werden.)

Danke schon mal, Gruß

BillMaier

Hallo zusammen,

abgesehen von den Links bin ich durch. Aktuell haben wir noch eine Redundanz mit Baustelle/Shell/Modi. Das hatte ich ja ursprünglich ausgelagert, habe die Erklärungen und Beispiele aber wieder hier rein genommen, damit man schnell einen Überblick bekommt. Sollen wir das erstmal so beibehalten oder was meint ihr?

Ausgelagert wurde Baustelle/Umgebungsvariablen/typische Anwendungsfälle.

Diesen Artikel hier würde ich im Wiki gerne "Umgebungsvariablen" nennen (+redirect).

Danke vorab für Korrekturen.

Gruß BillMaier

Hallo,

ich sag's mal gerade weg raus: Ich halte den Artikel für schlecht (oder meinetwegen auch nerdig), weil durch die sehr hohen Informationsdichte und null Beispiele für sehr schwer verständlich. Ich behaupte mal: wenn ich keine Ahnung von dem Thema hätte, wäre ich nach dem Lesen des Artikels keinen Millimeter schlauer, sondern wäre von einem Berg Informationen überflutet, die ich nicht zuordnen kann.

Ein paar Beispiele:

• 1. Satz: "Dieser Artikel beschäftigt der Definition von Umgebungsvariablen innerhalb von Konfigurationsdateien.": im gesamten restlichen Artikel taucht genau eine (!) Variable auf, und das in schlechter Form (siehe unten). Es wird noch nicht mal irgendwie irgendwo die Syntax erklärt, mit der Variablen in den Dateien hinterlegt werden. Richtiger wäre: Diese Artikel liste Dateien auf, in den Umgebungsvariablen hinterlegt werden können.

• Der Satz im Abschnitt "Überblick" "Generell gilt: Eine Umgebungsvariable gilt nur für das laufende Programm." stimmt doch nicht. Wenn man z.B. den HTTP_PROXY setzt, lesen den _alle_ Programme, die evtl. einen HTTP_PROXY nutzen. Außerdem steht der Satz im Widerspruch zum später im Artikel auftauchenden Satz "Sind alle Dienste und Programme betroffen?"

• Im Abschnitt "Grafischer Login - Für alle Benutzer" wird gesagt, dass die Ausführungsreihenfolge wichtig ist. Der Abschnitt schweigt sich aber völlig darüber aus, wie man die ändern könnte oder welche Ausführungsreihenfolge das System per Default hat.

• Abschnitt "Grafischer Login - Für einen einzelnen Benutzer": warum per echo ... >> in die Datei schreiben und diese nicht mit einem Editor öffnen?

• Zwei Abschnitte drunter taucht die Variable "LD_LIBRARY_PATH" aus dem Nichts auf. Es wird nirgends erklärt, wofür die gut und und warum man diese ggf. manuell ändern möchte.

• Tabelle "Environment einzelner oder aller Benutzer": Hier tauchen ein Haufen Konfig-Dateien auf - jedoch ohne jegliche Erklärung, welche wo für ist bzw. wo man wenn was eintragen sollte / muss / kann.

Gruß, noisefloor

Hhmm, hab nur mal kurz reingeschaut, der burner ist der Artikel nicht, da sind etliche Schwächen / Fehler, ohne jetzt auf alle eingehen zu wollen. Mir scheint das dem Autor selbst die Begrifflichkeiten oft nicht klar sind.

Ein paar Beispiele:

Umgebungsvariablen (Environment-Variablen) werden benötigt, um ein laufendes Programm mit Grundinformationen versorgen zu können und um sein Verhalten zu steuern. Generell gilt: Eine Umgebungsvariable gilt nur für das laufende Programm.

Nee. Alleine der Begriff "Programm" käme mir bei dem Thema nicht primär in den Sinn. "Grundinformationen", mmhh. Das ist was? Programme erhalten Parameter. fertig. Sie greifen auf Files, Datenströme, was-auch-immer-zu und werden so versorgt. Environmentvariablen sind eher ein Spezialfall.

Wenn man möchte, dass bei jedem Start des Programms oder für einen Benutzer eine Umgebungsvariable gelten soll, dann muss man sie in eine Konfigurationsdatei schreiben

Unsinn. Man "muss" nix in eine Konfigurationsdatei schreiben. Man setzt z.B. eine Environmentvariable in einer shell oder einem Script (oder eben auch in diversen Files) und verwendet sie. Oder man gibt den Wert direkt mit beim Aufruf. Das bspw. auch via alias. Da Übersetzungen und Formatierungen bei LANG=de z.T. grottig sind habe ich als Bsp.

1

alias free='LANG=en free'

zu bieten.

Anwendung von export wird hier scheints auch nicht besprochen. Namenskonventionen und mögliche Syntax? Fehlanzeige.

Es ist auch möglich, die Einträge in ~/.bashrc vorzunehmen. Dies ist jedoch in der Regel unnötig aufwändig, da dort enthaltene Befehle bei jedem Start einer Bash ausgeführt werden.

Dem stimme ich absolut nicht zu. Was ist daran aufwändig oder schlecht? Öffne ich eine shell/terminal/console, dann wird das Ding ausgeführt (... ~/.bashrc: executed by bash(1) for non-login shells ...) . Und?

Die "große" Tabelle hab ich mir nicht im Detail angeschaut, verwirrt mich aber eher als das ich sie übersichtlich finde. Welche Möglichkeitne es wo gibt wäre sicher gut zu wissen, aber deckt das diese Tabelle wirklich ab?

Zwei Dinge noch:

• das Ganze scheint mir sehr "GUI" (mit grafischer Oberfläche) lastig

• wieso wird hier Bezug auf die bash genommen? Nicht das ich was gegen die bash hätte, ist für mich ein quasi-Standard. Aber doch nicht bei Environmentvariablen?

Moinsn,

vielen Dank für Euer sehr direktes Feedback. Gut, dass es das Korrektiv der communitiy gibt.

Ehrlich: Ich bin einigermaßen überrascht, dass der Artikel so schlecht ankommt, insbesondere nach dem Zwischenstand:

noisefloor schrieb:

Ansonsten finde ich die aktuelle Strukturierung ganz gut.

und 8953005

Müsste jetzt nochmal nach schauen, aber ich war eigentlich der Meinung, auf dem gleichen Struktur-Weg unterwegs zu sein wie vor diesem Feedback.

Seebär schrieb:

Mir scheint das dem Autor selbst die Begrifflichkeiten oft nicht klar sind.

Der aktuelle Stand des Artikels ist ja ein Versuch, die überaus große Fülle an Informationen von kB aus Baustelle/Umgebungsvariable/a/revision/950141 einigermaßen verständlich zu strukturieren und einzudampfen. Ich gebe gerne zu, dass das ein ziemlicher Kraftakt war, weil doch sehr komplex in seiner Fülle. Die Reduzierung auf den jetzigen Stand geschah nach meiner persönlichen Einschätzung - nachdem ich bereits ziemlich weit im Thema drin war. Ich war aber motiviert das anzugehen, weil ich das Thema durchaus interessant fand und keine vergleichbaren Informationen im Netz gefunden habe. (Da wird in der Regel auf /etc/environment und /etc/profile verwiesen und das wars dann auch.) . Formulierungen habe ich größtenteils belassen.

Dadurch erkläre ich mir auch das

nerdig

.

Die "große" Tabelle hab ich mir nicht im Detail angeschaut, verwirrt mich aber eher als das ich sie übersichtlich finde. Welche Möglichkeitne es wo gibt wäre sicher gut zu wissen, aber deckt das diese Tabelle wirklich ab?

Für mich jetzt ja, aber ich muss die (rhetorische?) Frage an euch zurück geben, weil ich da wohl mittlerweile betriebsblind bin. Wir können aber auch /etc/security/pam_env.conf als "Allheilmittel" angeben und gut ist...

Noch drei Anmerkungen

1. Die Beispiele (die manches vielleicht verständlicher gemacht hätten) habe ich ausgelagert, weil das IMHO den Artikel sprengte.

2.

• das Ganze scheint mir sehr "GUI" (mit grafischer Oberfläche) lastig

Das kann ich nicht nachvollziehen. Ich habe - ganz am Ende der Bearbeitung - die Themen zur grafischen Oberfläche an den Anfang gepackt, weil das im Wiki i.d.R. am Anfang steht. Anteilmäßig finde ich das nicht "lastig".

3.

wieso wird hier Bezug auf die bash genommen? Nicht das ich was gegen die bash hätte, ist für mich ein quasi-Standard.

Genau deshalb. Wenn ich ein Kommando via SSH ausführe, läuft das dort in der Bash. Also interessiert mich, wo ich die Variablen dafür setzen muss, wenn ich welche benötige.

Aber doch nicht bei Environmentvariablen?

Baustelle/Umgebungsvariable/a/revision/950141 differenziert hier sehr stark zwischen den einzelnen Shell-Varianten. Übersichtlicher wird es dadurch aber nicht ...

Fazit: Ich wollte aus der Fülle einen Übersichtsartikel zu Konfigurationsdateien für Umgebungsvariablen schaffen - vielleicht die Quadratur des Kreises? Umgebungsvariable behandelt ja nur einen ganz kleinen Teilaspekt (ohne systemd und Konsorten).

Ich gebe das Thema an die Gemeinschaft: Bitte entscheidet ihr über das weitere Vorgehen.

Gruß BillMaier

Hallo,

das Grundproblem ist IMHO, dass der Artikel den Ansatz der allumfassenden Allumfassendheit hat - und genau an diesem Anspruch scheitern wird. Ich sehe eigentlich keine Chance, den Artikel allumfassend _und_ verständlich _und_ nachvollziehbar (und nicht episch lang) umzusetzen.

Daher würde ich eine "hands on" Ansatz vorschlagen:

1. Hauptartikel:

• (richtig) erklären, wozu Umgebungsvariablen da sind (und ggf. wo für nicht)

• allg. Konvention für Namen

• kurze Erklärung von export

• Beispiele, wann man ggf. UVs permanent setzen möchte

• kurze Erklärung zum Unterschied der Auswertung Login vs. Nicht Login Shell

2. zu erstellender Artikel "Umgebungsvariablen/Dateien":

• kurze Erklärung zu den _OOTB_ existierenden Dateien, wo UV hinterlegt sind

• Verweis auf den systemd/UV Artikel für systemd-spezifisches

3. Beispiele Artikel (existiert bereits)

BTW: wozu braucht man überhaupt eine "interaktive nicht-login Shell". Kommt das im Leben des Durchschnitts-Linuxnutzers vor? Ich nutzte seit ca. 15 Jahre Linux auf dem Desktop, kann mich aber an keinen bewussten "interaktive nicht-login Shell" Aufruf erinnern... Unabhängig davon kann ein allg. Artikel "Shell/Modi", wo das nachvollziehbar erklärt wird, nicht schaden. Unabhängig von den UVs.

Gruß, noisefloor

Hallo,

können wir gerne so machen. Die Frage ist, wer macht was? Wenn du das so im Kopf hast, magst du das mal so vorbereiten?

Was ist mit den Dingen, die ihr als falsch bezeichnet habt? Die andere Struktur wird den Inhalt erstmal nicht von selbst ändern. Da muss dann nochmal jemand ran.

BTW: wozu braucht man überhaupt eine "interaktive nicht-login Shell".

Da scheint die Tabelle bzgl. der ausgewerteten Dateien auch noch nicht zu passen. Allerdings ist deine Frage doch falsch gestellt. (Wenn ich was nicht kenne, frage ich natürlich auch "braucht man das?")... Jede Shell sieht ja zunächst erstmal gleich aus. Aber sie wird halt nicht immer gleich behandelt. Wird übrigens im Artikel - und ebenfalls in Baustelle/Shell/Modi erklärt mit einem Beispiel, das durchaus in deinen '15 Jahren Linux auf dem Desktop' mal vorgekommen sein dürfte: 'Aufruf eines Terminals in einer grafischen Umgebung'

kann mich aber an keinen bewussten "interaktive nicht-login Shell" Aufruf erinnern...

Genau das mein ich. Die Unterscheidung macht das System, nicht der Nutzer. Du nutzt das seit 15 Jahren ohne es zu wissen. Und wenn du ne UV setzt, hat das ggf. Auswirkungen - oder halt nicht. Das muss man verstehen oder hinnehmen. Hab mich am Anfang auch gefragt, was das eigentlich soll. Aber es gibt halt auch Dinge, die sind nun mal so. (wie gesagt, da hier /etc/profile.d/ ebenfalls ausgelesen wird, stimmt die Tabelle nicht. Richtiger scheint mir hier: https://unix.stackexchange.com/a/170499) Vielleicht liest ja kB hier noch mit und kann sich zum Inhalt nochmal äußern?)

Kann auch hier nochmal nachgelesen werden: http://www.fibel.org/linux/lfo-0.6.0/node51.html

• allg. Konvention für Namen

das hatte kB IMHO noch drin, inkl. dem erlaubten Zeichenraum für Namen und Werte. Nur zur Info...

Machst du mal die Aufteilung? Ich kann gerne weiter hier mit unterstützen, aber den Hut darf sich nun gerne ein anderer aufsetzen.

Gruß BillMaier

Ich hoffe durch folgende Überlegung keine weitere Komplexität in die Frage hineinzubringen:

Viele Systeme werden ja nur von einem interaktiven User überhaupt benutzt. Da könnte es erscheinen, als sei es Wumpe, ob eine UV systemweit gesetzt ist oder in den Konfigurationsdateien des Users.

Von wenigen Ausnahmen abgesehen habe ich meine Systeme alle exklusiv benutzt, und die meisten nicht mals zwischenzeitlich über ssh.

Vielleicht kann man von solch einem einfachen Fall ausgehen, und dann schildern, was man ändert, wenn man mehrere User hat. Was man ändert, wenn man Fernzugriff hat. Was man ändert, wenn Scripte/Dienste, die das System startet (cron, systemd) auf die UVs zugreifen sollen.

Dass man allgemein so spezifisch wie möglich arbeitet.

Meine geringe Erfahrung auf dem Gebiet macht es aber gut möglich, dass das kein guter Vorschlag ist sondern bloß gut gemeint. ☺

Hallo,

@BillMaier: ich stelle ja nicht in Frage, ob das sinnvoll ist oder nicht, eine "interaktive nicht-login Shell" zu nutzen, sondern es geht um den "real world use case". Ich finde, der Artikel ist aktuell auf einem viel zu abstrakten und damit schwer nachzuvollziehendem Level.

Das aktuelle Beispiele im Artikel, Dash aufzurufen, ist IMHO keins, was in der freien Wildbahn mit akzeptabler Häufigkeit vorkommt. Aka: schlechtes Beispiel. Auch das Beispiel andere su -l $USER finde ich schlecht, zumindest ohne Erklärung, warum man so was machen möchte.

Grundsätzlich bin ich auch bei user_unknown, dass der Fokus des Artikels auch "ich sitze vor meinem Rechner, bin eingeloggt und arbeite im Terminal" liegen sollte, weil das IMHO in der Tat der gängigste Anwendungsfall ist. ABER: die anderen Fälle sollten auch erklärt oder zumindest erwähnt werden. Einen Befehl per SSH auf einem z.B. Remote Server System abzusetzen ist ja IMHO auch nicht ungewöhnlich. Der Ausgangspunkt der Überarbeitung war ja, dass der ursprüngliche Artikel die verschiedenen Fälle, wann welche UV eingelesen wird, völlig ignorierte.

Wobei dieser "Fehler" ja IMHO nicht wirklich "schlimm" gewesen sein kann, weil sich über Jahre keiner beschwert hat, dass der Artikel falsch ist. Nichts desto trotz sollten wir die Überarbeitung / Verbesserung im Zuge unseres immer währenden Strebens nach der Vision der Perfektion des Wiki jetzt trotzdem durchziehen.

Gruß, noisefloor

Hallo,

noisefloor schrieb:

Wobei dieser "Fehler" ja IMHO nicht wirklich "schlimm" gewesen sein kann, weil sich über Jahre keiner beschwert hat, dass der Artikel falsch ist.

Er war nicht falsch. Er hat eben nur einen Teilaspekt behandelt und das mit der sehr allgemeine Überschrift.

Nichts desto trotz sollten wir die Überarbeitung / Verbesserung im Zuge unseres immer währenden Strebens nach der Vision der Perfektion des Wiki jetzt trotzdem durchziehen.

Bin, wie bereits erwähnt, gerne dabei.

Gruß BillMaier

noisefloor schrieb:

Ich finde, der Artikel ist aktuell auf einem viel zu abstrakten und damit schwer nachzuvollziehendem Level.

Liegt IMHO schon mal an den Formulierungen. Als ich das mit den unterschiedlichen Shells zum ersten Mal gehört habe, dachte ich ich bin im falschen Film. Andererseits hatte ich genau das schon erlebt: Ich setze eine Variable auf einem System via /etc/profile.d und will sie anschließend abfragen mit:

ssh <USER>@<HOST> 'echo $VAR'

Fehlanzeige, klappt nicht. Und dann wundert man sich und sucht nach environment vars. Wenn es uns jetzt gelingt, das sauber aufzuarbeiten → super. (Ich hatte ja in 8983450 schon mal nach Mithilfe gefragt, wenn die jetzt kommt umso besser. Die zugehörige Baustelle/Shell/Umgebungsvariablen enthält denke ich schon einen Teil dessen, was du vorhin bei deiner Struktur angesprochen hast.)

Zu den unterschiedlichen Shells bei den Umgebungsvariablen: Man könnte auch erst die Effekte beschreiben (sowas wie das SSH-Beispiel von oben), dann die dazugehörige Lösung und dann am Ende des Abschnitts "nebenbei" den Begriff erwähnen und auf Shell/Modi verlinken. Dann hätte man ein Maximum an Praxiserfahrung im Artikel.

Gruß BillMaier

Hallo,

wie ist der Stand?