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.
