[gelöst] $PATH-Problem bei Debian 10 und vanilla LaTeX

[EinSteiGer]

Wertes Forum,

ich bin mir nicht sicher, ob ich hier mit meiner jetzigen Frage im richtigen Forum bin (oder ob sie eher in ein TeX-Forum gehört).

Ich habe gestern auf einen alten Laptop Debian 10 samt Mate installiert.
Das hat funktioniert und daher habe ich heuteein vanilla TeX Live installiert und nach "Integrating vanilla TeX Live with Debian" (https://www.tug.org/texlive/debian.html) versucht das System in $PATH einzubinden.

Das hat funktioniert bis zu folgendem Punkt:

Code: Alles auswählen

# dpkg --install texlive-local_2019-1_all.deb
dpkg: Warnung: »ldconfig« wurde im PATH nicht gefunden oder ist nicht ausführbar
dpkg: Warnung: »start-stop-daemon« wurde im PATH nicht gefunden oder ist nicht ausführbar
dpkg: Fehler: 2 erwartete Programme nicht im PATH gefunden oder nicht ausführbar
Beachten Sie: PATH von root sollte normalerweise /usr/local/sbin, /usr/sbin und /sbin enthalten

Kann mir jemand einen Tipp geben, wo ich anfangen kann, um das Problem zu beheben? Gerne nehme ich auch Tipps an, wo ich zu meinem Problem etwas lesen kann. Und wenn ich dazu etwas finden kann: Weiß jemand, worauf ich achten muss (Hat sich zu PATH oder damit verbundenem etwas geändert zu Debian 10 [oder schon 9])?

Falls es sich nicht um ein Debian Problem, sondern doch eher um ein TeX-Problem handeln sollte, lassen Sie es mich bitte ebenfalls wissen, dann suche ich anderenorts weiter nach Rat.

Gerne gebe ich noch weitere Infos zum Rechner oder zur Installation, wenn benötigt.

Viele Grüße

[smutbert]

du hast mit

Code: Alles auswählen

su

root-Rechte erlangt?
Nimm stattdessen

Code: Alles auswählen

su -

oder

Code: Alles auswählen

su -l

[EinSteiGer]

Besten Dank! Das hat geholfen.

Jetzt würde mich doch nur noch interessieren, woher der Fehler kommt. Und warum ich damit früher keine Probleme hatte.

Unter https://manpages.debian.org/buster/manp ... .1.de.html habe ich gefunden:

Aus Gründen der Abwärtskompatibilität wechselt su standardmäßig nicht das aktuelle Verzeichnis und setzt lediglich die Umgebungsvariablen HOME und SHELL (plus USER und LOGNAME, falls der Ziel-Benutzer nicht Root ist). Es wird empfohlen, stets die Option --login (statt deren Kurzform -) zu verwenden, um durch Mischen der Umgebungen verursachte Nebenwirkungen zu vermeiden.

Aber was bedeutet das genau bzw. wo finde ich ggf. dazu mehr?

[KP97]

Aber was bedeutet das genau bzw. wo finde ich ggf. dazu mehr?

In einem der zig Beiträge hier im Forum...wenn man denn mal die SuFu bemüht...

[EinSteiGer]

Aber was bedeutet das genau bzw. wo finde ich ggf. dazu mehr?

In einem der zig Beiträge hier im Forum...wenn man denn mal die SuFu bemüht...

Danke für den Hinweis, da stelle ich mich vielleicht etwas blöd an...
Wenn ich

Code: Alles auswählen

su -l

suche, kommt nur Folgendes:

Information

Die folgenden Wörter deiner Suchanfrage wurden ignoriert, da sie zu häufig vorkommen: su -l.
Du musst mindestens ein Wort angeben, nach dem gesucht werden soll. Jedes Wort muss aus mindestens 3 Zeichen bestehen und darf ohne Platzhalter nicht mehr als 84 Zeichen haben.

Über geeignete Suchphrasen Ihrerseits würde ich mich freuen.

[smutbert]

Stimmt, ist etwas ungünstig zum suchen. Denn selbst wenn man einen Thread findet, verweist der auf die Suchfunktion – das Thema kommt ja seit Buster immer wieder und wieder und wieder und ... auf.

Entscheidend ist, dass »su -l« oder kurz »su -« eine Login-Shell starten, was bedeutet, dass viele Umgebungsvariablen, insbesondere der Suchpfad $PATH, in dem nach ausführbaren Dateien gesucht wird, neu gesetzt werden.

Das Verhalten von su ohne Optionen behält dagegen zum Teil die bestehende Umgebung bei, es bleibt also beim alten $PATH des aufrufenden Benutzers. Wobei das Verhalten von su ohne Optionen nicht standardisiert ist und sich gerade hinsichtlich $PATH beim Übergang von stretch auf buster geändert hat.
(Jetzt in buster ist es irgendwie etwas logischer, finde ich.)

[MaGe]

Jetzt in buster ist es irgendwie etwas logischer, finde ich.

Ist das logisch?

Alt:
privat@Mbox:~/Downloads/nv-codec-headers$ su
Passwort:
root@Mbox:/home/privat/Downloads/nv-codec-headers# make install

Neu:
privat@Mbox:~/Downloads/nv-codec-headers$ su -
Passwort:
root@Mbox:~# cd /home/privat/Downloads/nv-codec-headers
root@Mbox:/home/privat/Downloads/cd nv-codec-headers# make install


gruss MaGe

[hikaru]

Ist das logisch?

Alt:
privat@Mbox:~/Downloads/nv-codec-headers$ su
Passwort:
root@Mbox:/home/privat/Downloads/nv-codec-headers# make install

Neu:
privat@Mbox:~/Downloads/nv-codec-headers$ su -
Passwort:
root@Mbox:~# cd /home/privat/Downloads/nv-codec-headers
root@Mbox:/home/privat/Downloads/cd nv-codec-headers# make install

Jein. su kann/darf gar nicht "logisch" (im Sinne von konsistent) sein. Es macht potenziell drei Sachen:

1. Es verleiht Rechte eines anderen Users (ohne Usernamen die des Users root).
2. Es setzt $PATH auf den Wert, den der neue User in einer Login-Shell hätte.
3. Es setzt das aktuelle Verzeichnis auf $HOME des neuen Users.

Bei drei Optionen und beliebigen Kombinationen gibt es insgesamt 8 Kombinationsmöglichkeiten. Weder 1. noch 2. noch 3. zu machen ist nutzlos. 1., 2. und 3. zu machen ist sinnlos, denn dafür gibt es schon su -.
Die 6 übrigen Kombinationen führen zu inkonsistenten Zuständen. Nun kann man sich prinzipiell aussuchen, welche Art von Inkonsistenz es sein soll. Aus praktischen Erwägungen wird man immer 1. machen wollen. Das reduziert die Kombinationsmöglichkeiten auf 3:

A: 1.
B: 1. + 2.
C: 1. + 3.

Bis Stretch machte su B. Unter Buster macht es A. Und wenn Debian Lust hat, macht es ab Bulleye womöglich C. Der springende Punkt ist, dass su immer aus irgendjemandes Sicht etwas falsch (weil inkonsistent) machen muss, so lange es sinnvoll bleiben will.

[smutbert]

Es gibt ja noch weitere Variablen, die beibehalten werden können (oder nicht). Mir ist die ganze »su«/»su -« Problematik bewußt geworden, weil ich mit dem plötzlich notwendigen »su -« als root den ssh-agent des Benutzers nicht mehr verwenden konnte. Eigentlich ist mir das neue Verhalten also erst einmal auf die Nerven gegangen, aber wie gesagt empfinde ich nach einer Umgewöhnugszeit das jetzige Verhalten als einleuchtender (um nicht wieder logischer zu sagen).

Wenn das mit dem ssh-agent nicht wäre, würde ich ja sowieso dafür plädieren, dass sich su immer wie »su -« verhält und nichts von der Umgebung des aufrufenden Benutzers übrig bleibt.