Ich verwende Debian 10 und verwende , um aus einer Datei emacs 26.1ein PDF zu erstellen . Alles funktioniert einwandfrei, aber in letzter Zeit dauert es viel länger als früher. Wenn ich den Vorgang verfolge, sehe ich viele Zeilen wie die folgenden:orgxelatexxelatex
access("/home/loris/texmf/tex/latex/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/demo/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/docker/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/source/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/doc/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
Die einzelnen Dateien existieren zwar nicht, aber die Pfade, wie z.B.
/home/loris/texmf/tex/latex/mtheme-master
tun. Es scheint also, als würde eine rekursive Suche nach, in diesem Fall, longtable.styden gesamten Prozess verlangsamen. Die Datei ist tatsächlich hier verfügbar:
/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty
Es sieht also so aus, als ob die Suchreihenfolge für Pakete falsch ist. Kann mir jemand sagen, wo dies konfiguriert sein könnte? Keine der $TEXMF*Variablen scheint in meiner Umgebung definiert zu sein.
Antwort1
Wie ich in meinem Kommentar erwähne, wurde das Problem in meinem Fall dadurch verursacht, dass ich orgsowohl über VPN als auch über einen VPN-Zugriff auf die Datei zugegriffen habe sshfs. Diese zusätzlichen Schichten scheinen eine dramatische Verlangsamung zu verursachen.