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.

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 (`$` 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 (`$` 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 (`$` 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. 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. 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.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.

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: wie (`$` 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: stattfindet (`$` 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: eingeben (`$` 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. Es sei nicht verschwiegen, dass mit `sudo -i` ein gewisses Sicherheitsrisiko verbunden ist, weil dann eben auch Programme aus `/usr/local/bin` ausgeführt werden können. 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.

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: $ 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 interaktiven Shell Login-Shell stattfindet: $ 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. 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: $ 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. Es sei nicht verschwiegen, dass damit mit `sudo -i` ein gewisses Sicherheitsrisiko verbunden ist, weil dann eben auch Programme aus `/usr/local/bin` ausgeführt werden können. 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.

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: $ 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 interaktiven Shell stattfindet: $ sudo -i printenv PATH /usr/local/texlive/current/bin/x86_64-linux:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin Eventuell ist dann auch `/root/bin` mit im Pfad. Es sei nicht verschwiegen, dass damit ein gewisses Sicherheitsrisiko verbunden ist, weil dann eben auch Programme aus `/usr/local/bin` ausgeführt werden können. 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.