Kein Systempfad zu .../texlive/bin unter openSuse (Leap 15.1)

Das kann verschiedene Ursachen haben. Beispielsweise könnte in /etc/profile.d oder in /root bzw. /root/.config eine Konfigurationsdatei stehen, die tatsächlich PATH für root bzw. den Benutzer mit UID 0 anders setzt, so dass die Einstellungen aus /etc/zzz.texlive.sh wieder überschrieben werden.

Am wahrscheinlichsten ist allerdings, dass du

sudo texdoc texdoc

o. ä. verwendest, um als root zu arbeiten. sudo verwendet dann sicherheitshalber die Einstellungen aus /etc/sudoers. Darin findet sich bei OpenSUSE:

## Path that will be used for every command run from sudo
Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"
Defaults env_reset

Das sorgt dafür, dass nahezu das komplette Environment gelöscht und PATH auf das angegebene /usr/sbin:/usr/bin:/sbin:/bin gesetzt wird, wie ($ am Zeilenanfang symbolisiert hier den Shell-Prompt im Terminal-Fenster):

$ sudo printenv PATH
/usr/sbin:/usr/bin:/sbin:/bin

verrät.

Nun könnte man natürlich an der Stelle PATH ändern. Viel einfacher ist aber sudo mit Option -i aufzurufen, so dass die Initialisierung wie bei einer Login-Shell stattfindet ($ am Zeilenanfang symbolisiert hier den Shell-Prompt im Terminal-Fenster):

$ sudo -i printenv PATH
/usr/local/texlive/current/bin/x86_64-linux:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin

(Anmerkung: Eventuell ist dann auch /root/bin mit im Pfad das hängt von weiteren Einstellungen ab.) Es werden also die Skripte in /profile.d ausgeführt und auch der Pfad entsprechend erweitert. Damit ist dann also das binary-Verzeichnis von TeX-Live mit im Suchpfad und Dinge wie sudo -i tlmgr update -all funktionieren.

Für grafische Anwendungen verwendet man hingegen kdesu. Um zu sehen, wie PATH dabei gesetzt wird, kann man einfach einmal kdesu konsole aufrufen (das geht übrigens auch über System → Terminal - Superuser-Modus im Anwendungsmenü). Man wird nach dem root-Passwort gefragt, bevor das Teminal konsole mit root-Rechten startet. Dort dann echo $PATH eingeben ($ am Zeilenanfang symbolisiert hier den Shell-Prompt im Terminal-Fenster):

$ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/texlive/current/bin/x86_64-linux:/home/ijon/bin:/usr/local/bin:/usr/bin:/bin

Wie man sieht, ist dann wieder das Binary-Verzeichnis von TeX-Live im Suchpfad aber erst nach /sbin, /usr/sbin und /usr/bin. Wenn man also ein TeX-Live der Distribution installiert hat, werden dessen Binaries ggf. zuerst gefunden. (Wie man auch sieht, werden dabei sogar Binaries im `/bin/-Verzeichnis des Benutzers gefunden. Das ist ebenfalls ein Sicherheitsrisiko, das allerdings dadurch etwas gemindert wird, dass die Systemverzeichnisse zuerst durchsucht werden.)

(Anmerkung: kdesu texdoc texdoc funktioniert bei mir übrigens nicht, weil dabei versucht wird gimp für die Anzeige des PDFs zu starten, was aus Sicherheitsgründen bei mir nicht gelingt.)

Es sei nicht verschwiegen, dass mit sudo -i ebenfalls ein gewisses Sicherheitsrisiko verbunden ist, weil dann eben auch Programme aus /usr/local/bin ausgeführt werden können (genau wie mit kdesu).

Empfehlen würde ich übrigens einen Benutzer für die Administration von TeX Live einzurichten. Dann kann man das TeX-Live-Basisverzeichnis diesem Benutzer übereignen und künftig über diesen Benutzer die komplette TeX-Live-Installation ganz ohne root-Rechte administrieren. Das ist sicherer. TeX Live ist extra so ausgelegt, dass das funktioniert. Notfalls kann man auch den normalen Benutzer dafür verwenden. Dann geht man aber das Risiko ein, dass es jemand gelingt über teilweise Übernahme dieses Benutzers Programme im Binary-Verzeichnis von TeX-Live auszutauschen.