TeXwelt wurde neu installiert. Es funktionieren noch nicht alle Features und auch an den deutschsprachigen Formulierungen wird verbessert. Danke für eure Geduld.

Hallo,

texlive 2019 in openSuse Leap 15.1 installiert, allerdings nicht unter /usr/local/texlive, sondern unter /local/texlive. Also habe ich mir hier https://github.com/rolfn/texlive-dummy-opensuse die Quelle des Pakets gezogen und im Makefile den Pfad angepasst. Paket gebaut mit »make« und installiert. Erfolg: unter /etc/profiles.d/ gibt es zzz.texlive.sh und zzz.texlive.csh . In beiden ist, wie gewollt, angegeben:

TL_DIR="/local/texlive/2019"

Aber wenn ich als root z.B. eingebe

texdoc texdoc

erhalte ich

texdoc: command not found

Wie auch, denn

echo $PATH

als root enthält /local/texlive/2019/bin eben nicht, sondern nur

/sbin:/bin:/usr/sbin:/usr/bin

Was mache ich falsch?

Als Nutzer kann ich aus *.tex Dateien PDFs herstellen (bis auf einen mir rätselhaften Fehler bei LuaLaTeX, aber dem gehe ich nach, wenn das hier gelöst ist).


Edit

Auf die Antwort von Ijon (vielen Dank!):

sudo -i printenv PATH

ergibt folgendes Ergebnis:

/local/texlive/2019/bin/x86_64-linux:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin

Ähm, was bedeutet das? (Die Vorschläge, texlive woanders zu installieren oder einen zusätzlichen Nutzer einzurichten, überblicke ich noch nicht, das muss ich mir erst überlegen. So eine Änderung hat ja auch Auswirkungen auf die Neuinstallation, auf das Backup etc.)

gefragt 13 Jul, 14:15

Keks%20Dose's gravatar image

Keks Dose
15636
Akzeptiert-Rate: 0%

bearbeitet 13 Jul, 15:02

/local solltest du nicht verwenden. Das ist kein Top-Level-Verzeichnis, das im Linux-Filesystem-Standard vorkommt. Besser alles nach /usr/local oder /opt/ verschieben.

(13 Jul, 14:41) Ijon Tichy

@ijon-tichy Ich verwende /local eben deswegen seit zehn Jahren. Ohne in irgendwelche Interna von Linux einzugreifen, kann ich /local als eigene Partition betreiben, die eine Neuinstallation unangerührt überlebt. Hm, wie mache ich es, diese Kommentar an Dich (I. T.) zu adressieren?

(13 Jul, 14:49) Keks Dose

Das geht mit /usr/local genauso und ist auch so gedacht. Mit /opt geht es prinzipiell ebenfalls, allerdings werden da teilweise auch schlecht integrierte Pakete von der Linux-Distribution installiert. Bei openSUSE-Paketbauern (beispielsweise auf im OBS) ist die Verwendung von /opt inzwischen verpönt. Die sind angehalten, die Integration korrekt vorzunehmen. Andere Distributionen machen unterschiedlich regen Gebrauch von /opt.

@ijon genügt übrigens. @ijon-tichy und @ijon tichy geht aber auch. ;-)

(13 Jul, 14:53) Ijon Tichy

Ich rate übrigens auch davon ab texdoc als root aufzurufen. Dafür besteht genau genommen keine Notwendigkeit. Das kann man genauso gut als einfacher Benutzer. Je seltener man root-Rechte einsetzt, desto weniger kann dabei schief gehen. Im Idealfall braucht man root tatsächlich nur, für Installation und Update des Linux-Systems und einige grundlegende Konfigurationsmaßnahmen.

(13 Jul, 15:22) Ijon Tichy

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 SystemTerminal - 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.

Permanenter link

beantwortet 13 Jul, 14:52

Ijon%20Tichy's gravatar image

Ijon Tichy
8.8k31024
Akzeptiert-Rate: 56%

bearbeitet 13 Jul, 15:32

Ich verwende kein »sudo«. Ich habe meine Frage ergänzt -- Danke für Deine Mühe.

(13 Jul, 15:03) Keks Dose

@Keks Wie wirst du dann zu root? Ich hoffe, du verwendest keinen grafischen Login. Sollte man als root niemals tun. Als root immer nur einzelne Programme, maximal das Terminal (bei KDE also konsole) als root starten. root sollte übrigens LaTeX auch nur in Ausnahmen aufrufen. Dafür gibt es auch keinen rechten Grund. Man macht das besser als einfacher Benutzer und übereignet dann ggf. das Ergebnis an root.

(13 Jul, 15:19) Ijon Tichy

konsole, dort »su«. Darüber habe ich bisher immer texlive aktuell gehalten. Als das dieses Jahr nicht mehr funktionierte aus Gründen, die mir unklar sind, habe ich eine bash.bashrc.local in /etc geschrieben, die den Pfad zu /texlive .../bin enthalten hat. Im Moment räume ich auf, weil mir irgendwas im Zusammenhang mit LuaTeX auf die Füsse gefallen ist und ich auch seltsame Fehlerquellen ausschließen will, bevor ich frage.

(13 Jul, 15:31) Keks Dose

@Keks: Bei Verwendung von su wird aber normalerweise das Environment übernommen und eine Login-Shell ausgeführt (wodurch dann PATH ggf. erweitert wird). Genau das macht su auch so gefährlich, weshalb man es AFAIK besser nicht verwenden sollte. Ich bekomme nach su mit echo $PATH wie erwartet /usr/local/texlive/current/bin/x86_64-linux:/home/ijon/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/bin, was wirklich kritisch ist!

BTW: Bei diversen Linux-Distributionen gibt es in der Voreinstellung gar keinen Login-User root. Dann funktioniert su gar nicht erst.

(13 Jul, 15:40) Ijon Tichy
Deine Antwort
Vorschau umschalten

Folgen dieser Frage

Per E-Mail:

Wenn sie sich anmelden, kommen Sie für alle Updates hier in Frage

Per RSS:

Antworten

Antworten und Kommentare

Markdown-Grundlagen

  • *kursiv* oder _kursiv_
  • **Fett** oder __Fett__
  • Link:[Text](http://url.com/ "Titel")
  • Bild?![alt Text](/path/img.jpg "Titel")
  • nummerierte Liste: 1. Foo 2. Bar
  • zum Hinzufügen ein Zeilenumbruchs fügen Sie einfach zwei Leerzeichen an die Stelle an der die neue Linie sein soll.
  • grundlegende HTML-Tags werden ebenfalls unterstützt

Frage-Themen:

×39
×38
×1

gestellte Frage: 13 Jul, 14:15

Frage wurde gesehen: 803 Mal

zuletzt geändert: 13 Jul, 15:40