staging.inyokaproject.org

Hallo,

@kB vielen Dank für deine "Wahnsinns-Recherche". Damit dürftest du ja nun jede erdenkliche Support-Anfrage zu Umgebungsvariablen beantworten können. Mein größter Respekt gilt allerdings deiner Reaktion in https://forum.ubuntuusers.de/post/8951013/ . Das habe ich hier so noch selten erlebt - schon gar nicht unter diesen Umständen. Das gibt mir Hoffnung für dieses Portal! 👍

Zum Thema:

• Ich stimme den anderen Wikingern zu: Der Artikel erschlägt. Wenn ich was suchen würde wüsste ich nicht, wo ich ich das im Artikel tun soll.

• Ich stimme kB zu: Meine Support-Anfragen zu Umgebungsvariablen im Internet wurden bisher nie ausreichend beantwortet. War meist ein Rumgestocher / trial-and-error. Leider hätte mir der Artikel in meinen praktischen Problemen auch nicht weiter geholfen.

Die Herausforderung, das nun praxisnah zu bekommen, ist eine große. Ich glaube, ich muss mir das erstmal (als Buch ? 😉 ) ausdrucken, wenn ich dazu konkreter Stellung geben soll.

Reichen dir erstmal die Antworten meiner Vorredner oder benötigst du aktuell konkret Hilfe?

Gruß BillMaier

noisefloor schrieb:

zu viele Abschweifungen zu anderen Themen (wie Unterschiede Bash und Dash oder das Setzen von Variablen für systemd)

Das Setzen von Umgebungsvariablen für systemd-Units gehört absolut in den Artikel, wie ich schon weiter oben angemerkt hatte.

(Nach meiner Beobachtung gehen immer mehr Dienste (nur in Ubuntu?) dazu über, die benötigten Variablen in /etc/default/<DIENST> abzulegen - was vll. eine kurze Notiz wert wäre.)

Gruß BillMaier

Hallo,

Das Setzen von Umgebungsvariablen für systemd-Units gehört absolut in den Artikel, wie ich schon weiter oben angemerkt hatte.

Was spricht denn gegen einen eigenen Unterartikel bei systemd, der dann im Umgebunsvariable Artikel verlinkt wird? Wenn der Artikel Umgebungsvariable so wie so unterteilt wird...

Gruß, noisefloor

Nichts. 👍

(Ich hab ja nicht gesagt, wie es in den Artikel gehört → das kann auch ein Hinweis mit Link sein)

😬

BillMaier schrieb:

[…] @kB vielen Dank für deine "Wahnsinns-Recherche".[…]

Danke für Deine freundliche Aufmunterung!

• Ich stimme den anderen Wikingern zu: Der Artikel erschlägt. […]

Ich hatte bereits vor Beginn der Überarbeitung geahnt, das dies eine unübersichtliche Thematik ist. Meine Befürchtungen haben sich bei der Bearbeitung grandios gesteigert bewahrheitet. Ich bin daher auch selbst mit dem bisherigen Ergebnis nicht glücklich.

• Ich stimme kB zu: Meine Support-Anfragen zu Umgebungsvariablen im Internet wurden bisher nie ausreichend beantwortet. War meist ein Rumgestocher / trial-and-error. Leider hätte mir der Artikel in meinen praktischen Problemen auch nicht weiter geholfen.

Das sollte konkret der Abschnitt „Wo soll ich als Administrator was ändern?“ mit den von dort verzweigten Unter-Abschnitten heilen, in denen ja situationsabhängig konkrete Handlungen mit möglichen Dateien vorgeschlagen werden.

[…] ich dazu konkreter Stellung geben soll

Gerne. Und ich warte auch gerne darauf.

[…] benötigst du aktuell konkret Hilfe?

Einige technische Auskünfte zu folgenden Fragen könnten meine eigene Meinung zum weiteren Vorgehen beeinflussen:

1. Wenn ich selber Wiki-Seiten anlege, landen diese doch automatisch im Status Baustelle?

2. Können solche selbst angelegten Baustellen-Seiten nach Fertigstellung und Akzeptanz an zweckmäßige Stellen in der Hierarchie verschoben werden oder bringt das Pein für das Wiki-Team? Ich denke dabei z.B. an solche Aktionen wie: Baustelle/Umgebungsvariable/systemd-Aspekte –> systemd/Umgebungsvariable, wobei das endgültige Ziel beim Anlegen der Baustelle noch nicht feststeht bzw. sich nach Diskussion den Inhalts auch ändern könnte.

3. Was sollte ich beim Anlegen solcher Baustellen-Seiten außer Wikiartikel anlegen noch beachten?

kB schrieb:

1. Wenn ich selber Wiki-Seiten anlege, landen diese doch automatisch im Status Baustelle?

Korrekt.

1. Können solche selbst angelegten Baustellen-Seiten nach Fertigstellung und Akzeptanz an zweckmäßige Stellen in der Hierarchie verschoben werden

Ja, kein Problem.

oder bringt das Pein für das Wiki-Team?

Nein, alles gut.

Ich denke dabei z.B. an solche Aktionen wie: Baustelle/Umgebungsvariable/systemd-Aspekte –> systemd/Umgebungsvariable, wobei das endgültige Ziel beim Anlegen der Baustelle noch nicht feststeht bzw. sich nach Diskussion den Inhalts auch ändern könnte.

Da könnte höchstens die Einleitung etwas anders aussehen, weil der Artikel in einem anderen Kontext abgelegt wird. Muss aber nicht mal. Das ist aber eine Kleinigkeit - und das Verschieben innerhalb der Hierarchie wie gesagt überhaupt kein Problem.

1. Was sollte ich beim Anlegen solcher Baustellen-Seiten außer Wikiartikel anlegen noch beachten?

Ähm, mir fällt momentan nichts ein. Falls doch noch muss das spätestens dann in den von dir verlinkten Artikel 😉

Wo soll ich als Administrator was ändern?

Das ist meine Hauptfrage, wenn ich so einen Artikel lese. Dass das alles saumäßig komplex ist sehe ich nun auch. Aber genau dahin sollte der Leser relativ schnell kommen. Wie von dort die Benutzerführung aussieht ist nochmal eine andere Sache. Wie gesagt, ich hab mir das jetzt mal ausgedruckt und melde mich die Tage bzgl. Vorschlag.

Viele Grüße bis dahin

BillMaier

Die Idee, das lange Wort im Text abzukürzen, finde ich richtig.

Mit der Einführung der Abkürzung würde ich aber auch eine Konvention einführen, das "UV" für eine/die Umgebungsvariable (Einzahl) und "UVs" als Mehrzahl verwendet wird, und das dann auch machen. Ich hatte Mehrfach Schwierigkeiten Ez./Mz. auseinanderzuhalten.

Leider sind diese Konfigurationsdateien und auch deren Syntax/Formate abhängig vom jeweiligen Programm.

Wahrscheinlich gibt es ja in den meisten Fällen Gründe für eine eigene Syntax.

Das Beispiel "root=UUID=b6b72769-7ed0-48ac-84fe-f226f0728df3" wirft die Frage auf, was dann mit der Aussage weiter oben gemeint ist, wo es heißt: "UV auf Systemebene verwenden keine Kleinbuchstaben."

Wenn man schreibt

Die Übergabe von Passwörtern über UV ist möglich; jedoch wird von dieser unsicheren Praxis dringend abgeraten!

und als Beispiel 4 Codezeilen zeigt, in denen 2x Passwörter verwendet werden, wirkt das widersinnig; so als würde davon abgeraten, aber als würde es dann doch letztlich jeder so machen. Es fallen einem nicht mal andere Beispiele ein, so dass man zeigen könnte, was man zeigen will.

Interaktive ./. nicht-interaktive Shell:

Das ist doch ein kaufmännisches Saldozeichen, oder? Gemeint ist wohl die Alternative

Interaktive/nicht-interaktive Shell:

und die wird ohne Leerzeichen drumrum gesetzt.

Login- ./. nicht-Login-Shell:

Dito.

Eine „Login-Shell“ darf nicht mit dem Login-Vorgang verwechselt werden und eine Login-Shell hat nichts mit der Anmeldung eines Benutzers zu tun.

Dass auch Shells, die nicht beim Login gestartet wurden, Loginshells sein können bedeutet nicht, dass der Begriff nichts mit der Anmeldung eines Users zu tun hat. Sie sind nicht zwingend an den Login gebunden, ja, und über Parameter als Loginshell startbar. Aber wieso heißen sie Loginshell, wenn sie nichts mit dem Login zu tun haben?

Die 4. Aufrufart „nicht-interaktive nicht-Login-Shell“ wird regelmäßig von Systemprogrammen für die Abarbeitung von Shell-Skripten durch die System-Shell angewendet.

Ich glaube das "regelmäßig" ist hier ein sprachlicher False-Friend. Heißt das "jeden Montag" oder "alle 7 Male" oder welche Regelmäßigkeit ist da am Werk?

Die Benutzerdatenbank benennt für jeden zur Anmeldung befähigten Benutzer das Programm, welches für ihn als initiale Shell benutzt wird. (Hervorhebung uu)

Wie wär's mit "anmeldbaren Benutzer" oder "berechtigten Benutzer"? Geht es um die Abgrenzung von von Diensten, die sich niemals selbst anmelden, wie lp, mail, saned und deshalb keine Loginshell haben?

user_unknown schrieb:

Die Idee, das lange Wort im Text abzukürzen, finde ich richtig.

Ja, ich auch. Andere nicht. Wenn ich richtig gezählt habe, sind jetzt zwei für die Abkürzung und einer dagegen.

[…] Konvention einführen, das "UV" für eine/die Umgebungsvariable (Einzahl) und "UVs" als Mehrzahl verwendet wird […]

Guter Vorschlag. Werde allerdings die deutsche Mehrzahlbildung UV/UVn verwenden.

Leider sind diese Konfigurationsdateien und auch deren Syntax/Formate abhängig vom jeweiligen Programm.

Wahrscheinlich gibt es ja in den meisten Fällen Gründe für eine eigene Syntax.

Natürlich. Mein Wort „leider“ war mitfühlend für den Administrator gemeint, der die verschiedene Syntax erinnern muss. Das Wort werde ich einfach streichen.

Das Beispiel "root=UUID=b6b72769-7ed0-48ac-84fe-f226f0728df3" wirft die Frage auf, was dann mit der Aussage weiter oben gemeint ist, wo es heißt: "UV auf Systemebene verwenden keine Kleinbuchstaben."

Weiter oben wurde eine sinnvolle, aber nicht verpflichtende Konvention beschrieben. Nicht alle richten sich danach.

Wenn man schreibt

Die Übergabe von Passwörtern über UV ist möglich; jedoch wird von dieser unsicheren Praxis dringend abgeraten!

und als Beispiel 4 Codezeilen zeigt, in denen 2x Passwörter verwendet werden, wirkt das widersinnig; so als würde davon abgeraten, aber als würde es dann doch letztlich jeder so machen. Es fallen einem nicht mal andere Beispiele ein, so dass man zeigen könnte, was man zeigen will.

In der Tat übergeben manche Leute Passworte per UV, und diese Praxis ist unsicher. Somit ist mein Hinweis sachlich richtig, allerdings sollte ich ihn nicht in diesem Wiki-Artikel unterbringen, sondern mich hier auf die Möglichkeiten zur Definition von UV beschränken. Ich werde also statt Passworten andere Beispiele verwenden.

Interaktive ./. nicht-interaktive Shell:

Das ist doch ein kaufmännisches Saldozeichen, oder? Gemeint ist wohl die Alternative […]

Ja, die Kaufleute verwenden auch dieses Zeichen „./.“, allerdings nicht mit der von mir gemeinten Verwendung. Ich verwende es als Abkürzung für „versus“ in der Absicht, die Eigenschaften zweier Parteien/Standpunkte/Ausprägungen zu diskutieren. Also eher wie im Rubrum eines juristischen Verfahrens, z.B. „Adolf Niemand ./. Beate Niemand-ist-gemeint“. Offenbar ist aber diese Bedeutung des Zeichens „./.“ nicht so allgemein verständlich, wie ich annahm. Ich werde daher über Alternativen nachdenken.

[…] Aber wieso heißen sie Loginshell, wenn sie nichts mit dem Login zu tun haben?

Das wird erklärt durch den Satz: „Die Bezeichnung der Aufrufart als „Login-Shell“ erklärt sich aus der Verwendung dieser Aufrufart beim Start der initialen Shell eines Benutzers direkt nach der Anmeldung.“

Die 4. Aufrufart „nicht-interaktive nicht-Login-Shell“ wird regelmäßig von Systemprogrammen für die Abarbeitung von Shell-Skripten durch die System-Shell angewendet.

[…] welche Regelmäßigkeit ist da am Werk?

Die in diesem Fall wirksame Regel lautet: Benutze sie immer, es sei denn, es wird ausdrücklich etwas anderes verlangt. Werde aber das Wort „regelmäßig“ an dieser Stelle vermeiden.

[…] zur Anmeldung befähigten Benutzer […]

Wie wär's mit […]

Hier empfinde ich meine Formulierung treffender als Deine Vorschläge.

Danke für Deine konstruktiven Hinweise!

kB schrieb:

[…] Konvention einführen, das "UV" für eine/die Umgebungsvariable (Einzahl) und "UVs" als Mehrzahl verwendet wird […]

Guter Vorschlag. Werde allerdings die deutsche Mehrzahlbildung UV/UVn verwenden.

Dann sagst Du auch nicht "Auf der Autobahn hatten sich 3 LKWs verkeilt" sondern "3 LKWn", selbst wenn es ein wenig wie Elkewehen klingt? Was immer das sein soll - deutsch ist es nicht. ☺

Als Nichtwikiteamler zählt meine Stimme übrigens höchstens 0,6 Stimmen. Vielleicht in den Zwischenüberschriften in Langform lassen, und nur im Fließtext abkrzn.?

Interaktive ./. nicht-interaktive Shell:

Das ist doch ein kaufmännisches Saldozeichen, oder? Gemeint ist wohl die Alternative […]

Ja, die Kaufleute verwenden auch dieses Zeichen „./.“, allerdings nicht mit der von mir gemeinten Verwendung. Ich verwende es als Abkürzung für „versus“ in der Absicht, die Eigenschaften zweier Parteien/Standpunkte/Ausprägungen zu diskutieren. Also eher wie im Rubrum eines juristischen Verfahrens, z.B. „Adolf Niemand ./. Beate Niemand-ist-gemeint“. Offenbar ist aber diese Bedeutung des Zeichens „./.“ nicht so allgemein verständlich, wie ich annahm. Ich werde daher über Alternativen nachdenken.

Brauchst Du nicht - es gibt "Interaktive/nicht-interaktive Shell". ☺

[…] Aber wieso heißen sie Loginshell, wenn sie nichts mit dem Login zu tun haben?

Das wird erklärt durch den Satz: „Die Bezeichnung der Aufrufart als „Login-Shell“ erklärt sich aus der Verwendung dieser Aufrufart beim Start der initialen Shell eines Benutzers direkt nach der Anmeldung.“

Nein, das erklärt, wieso der Begriff etwas mit dem Login zu tun hat, nicht wieso er nichts damit zu tun hat.

Die 4. Aufrufart „nicht-interaktive nicht-Login-Shell“ wird regelmäßig von Systemprogrammen für die Abarbeitung von Shell-Skripten durch die System-Shell angewendet.

[…] welche Regelmäßigkeit ist da am Werk?

Die in diesem Fall wirksame Regel lautet: Benutze sie immer, es sei denn, es wird ausdrücklich etwas anderes verlangt. Werde aber das Wort „regelmäßig“ an dieser Stelle vermeiden.

Danke, ein meist häßliches Füllwort unserer Zunft.

Hier empfinde ich meine Formulierung treffender als Deine Vorschläge.

Danke für Deine konstruktiven Hinweise!

Da kann man dann wenig machen.

Danke ebenso.

user_unknown schrieb:

[…] Dann sagst Du auch nicht "Auf der Autobahn hatten sich 3 LKWs verkeilt" sondern "3 LKWn"

Nein, so spreche ich nicht. Im Deutschen ist die Mehrzahl von LKW wieder LKW ohne weitere Markierung:

• Ez. der Lastkraftwagen – Mz. die Lastkraftwagen, wenn man hier den Numerus syntaktisch markieren will, muss man es über Artikel machen.

• Aber: Ez. die Umgebungsvariable – Mz. die Umgebungsvariablen, hier bringt ein Artikel nichts, aber die Endung.

• Eine Markierung des Plural durch ein angehängtes „s“ ist im Deutschen syntaktisch falsch und nur dann zulässig, wenn es sich um ein Lehnwort aus dem Englischen handelt (vgl. „das Kind – die Kinder“, aber natürlich nicht „das Baby – die Babyer“, sondern Babys!) Ich werde mich aber noch mit dem Duden beraten.

[…] Vielleicht in den Zwischenüberschriften in Langform lassen, und nur im Fließtext abkrzn.?

Auch eine nette Variante. Hat aber den unschönen Nebeneffekt, dass dann im Inhaltsverzeichnis die Titel abgeschnitten erscheinen.

[…] Das wird erklärt durch den Satz: „Die Bezeichnung der Aufrufart als „Login-Shell“ erklärt sich aus der Verwendung dieser Aufrufart beim Start der initialen Shell eines Benutzers direkt nach der Anmeldung.“

Nein, das erklärt, wieso der Begriff etwas mit dem Login zu tun hat, nicht wieso er nichts damit zu tun hat.

OK, habe Deinen Punkt nun verstanden. Die Aufrufart „Login-Shell“ hat etwas mit dem Login zu tun: Sie wurde für eigens diesen Vorgang erfunden, kann nun aber auch anders eingesetzt werden. Meine Formulierung, „… hat nichts mit der Anmeldung zu tun …“ ist also zu ausschließend und dadurch falsch.

kB schrieb:

user_unknown schrieb:

[…] Dann sagst Du auch nicht "Auf der Autobahn hatten sich 3 LKWs verkeilt" sondern "3 LKWn"

Nein, so spreche ich nicht. Im Deutschen ist die Mehrzahl von LKW wieder LKW ohne weitere Markierung:

• Ez. der Lastkraftwagen – Mz. die Lastkraftwagen, wenn man hier den Numerus syntaktisch markieren will, muss man es über Artikel machen.

• Aber: Ez. die Umgebungsvariable – Mz. die Umgebungsvariablen, hier bringt ein Artikel nichts, aber die Endung.

Dass die Mehrzahl von Umgebungsvariable Umgebungsvariablen ist, ist unstrittig. Es geht um die Mehrzahl von UV. Ein Vau, zwei Vaus.

• Eine Markierung des Plural durch ein angehängtes „s“ ist im Deutschen syntaktisch falsch und nur dann zulässig, wenn es sich um ein Lehnwort aus dem Englischen handelt (vgl. „das Kind – die Kinder“, aber natürlich nicht „das Baby – die Babyer“, sondern Babys!) Ich werde mich aber noch mit dem Duden beraten.

Ein Uhu, zwei Uhus, ein Auto, zwei Autos - nix mit Englisch. Ein Gnu, zwei Gnus. Ein Motto, zwei Mottos ...

Ich schlage für das weitere Vorgehen eine Aufteilung in 4 Seiten vor:

• Hauptseite erhält nach einer kurzen Einleitung mit Verweisen auf die Folgeseiten im wesentlichen die jetzigen Kapitel „Wo soll ich als Administrator was ändern?“ nebst Unterkapiteln und „Export von Variablen“, jedoch in anderer Zusammenstellung und als einzige Anwendung das Setzen/Ändern der Variable PATH.

• Unterseite 1 stellt die verschiedenen möglichen Dateien mit den diese betreuenden Programmen vor, jedoch ohne die systemd-Aspekte.

• Unterseite 2 wie Unterseite 1, jedoch nur die systemd-Aspekte. Damit eröffnet sich die Möglichkeit, diese Seite zu den anderen systemd-Seiten zu stellen.

• Unterseite 3 enthält die Praxisbeispiele.

Unabhängig vom weiteren Vorgehen sind natürlich konstruktive Hinweise weiterhin willkommen.

Hallo,

klingt IMHO gut.

Beschäftige mich gerade mit den systemd Sachen - kannst also erst mal an den anderen Seiten arbeiten bzw. die entsprechenden Baustellen erstellen.

Gruß, noisefloor

Hallo zusammen, ich habe mir erlaubt, eine neue Revision zur erstellen mit einem Vorschlag zur Strukturierung. Die Systemd-Verlinkungen habe ich bereits berücksichtigt / zumindest angedeutet. (Es ist alles noch keine Reinschrift!) Ich habe außerdem aus meiner Sicht kleinere "zu komplizierte Hintergrundinformationen" teilweise entfernt, wenn ich sie für nicht relevant fand.

Erst hinterher fand ich kBs Vorschlag (wieder?) - den ich nicht übergehen wollte: Teilweise trifft mein Vorschlag deine genannten Punkte, teilweise nicht. Zur Transparenz:

Ich schlage für das weitere Vorgehen eine Aufteilung in 4 Seiten vor:

• Hauptseite erhält nach einer kurzen Einleitung

umgesetzt

mit Verweisen auf die Folgeseiten

todo

im wesentlichen die jetzigen Kapitel „Wo soll ich als Administrator was ändern?“

umgesetzt

nebst Unterkapiteln und „Export von Variablen“, jedoch in anderer Zusammenstellung und als einzige Anwendung das Setzen/Ändern der Variable PATH.

Könnte auch in die Unterseite mit den Praxisbeispiele, oder? - oder alternativ in einen Artikel wie Shell/Umgebungsvariablen. Wo wäre das sinnvoll? (Frage geht hauptsächlich ans Wikiteam bzw. an Leute, die sich mit der Wiki-Struktur besser auskennen)

Unabhängig vom weiteren Vorgehen sind natürlich konstruktive Hinweise weiterhin willkommen.

Ich könnte mir vorstellen, Punkt 1-7 (siehe Inhaltsverzeichnis) weiterhin in diesem Artikel zu haben.

Weiterhin zu klären aus meiner Sicht:

1. welche Unterartikel sind noch nötig?

2. Kann die Unterscheidung zu Login/Nicht-Login-Shell in einen separaten Unterartikel in Shell ?

3. Umgebungsvariable/#Environment-einzelner-Benutzer - nimmt Bezug auf die Unterscheidung der Shells. Wie gehen wir damit um? (vgl. Punkt 2.)

So, ich hoffe ich konnte etwas zur Lösung beitragen.

Gruß BillMaier

Nach Absprache mit BillMaier, da meine Motivation z.Zt. schwächelt, BillMaier bei der Strukturierung/Aufteilung schon gute Fortschritte gemacht hat und viele Köche bekanntlich den Brei verderben, übergebe ich vertrauens- und hoffungsvoll die Baustelle in seine Hände.