.aux-Problem: Rekompilieren nach Fehlerbehebung bricht ab

Fragen und Probleme, die nicht den obigen Kategorien zugeordnet werden können


ehwlt
Forum-Anfänger
Forum-Anfänger
Beiträge: 37
Registriert: Sa 5. Mär 2011, 13:29

.aux-Problem: Rekompilieren nach Fehlerbehebung bricht ab

Beitrag von ehwlt »

Hallo,

ich schreibe als HiWi ein Skript. Seit ein paar Tagen läßt sich das Dokument nicht kompilieren, wenn ich einen Syntaxfehler mache und behebe. Wenn also im Quelltext alles wieder stimmt, dann erzeugt die .aux-Datei einen Fehler, weil sie in der letzten Zeile einen unvollständigen Eintrag enthält. Die Fehlermeldung in TeXworks lautet:
(./skript.aux)
Runaway argument?
{\contentsline {chapter}{\numberline {7}\IeC {\"U} 
! File ended while scanning use of \@writefile.
<inserted text> 
                \par 
l.118 \begin{document}
                      
? 
Der letzte Eintrag bricht also in der Überschrift ab, nach dem Ü (erster Buchstabe). Jedes Mal die aux-Datei löschen zu müssen ist ziemlich lästig, deswegen wüßte ich gern, wo der Fehler liegt. Soweit ich aus meinen Recherchen im WWW schließen kann, habe ich wohl irgendwo ein »fragiles« Kommando oder dergleichen benutzt. Aber genau zu diesem Thema habe ich nichts gefunden.

Ich hab auch schon aus dem Ü in der Überschrift ein U gemacht, hat aber nichts gebracht. Da bricht der letzte Eintrag in der aux-Datei nur ein kleines Stück weiter in dieser Überschrift ab (nach »Ubertragun«).

Der Fehler läßt sich nicht immer reproduzieren, aber fast immer.

Ist das Verhalten vielleicht typisch für einen häufig gemachten Fehler?

PS: Ich habe hier gerade gesehen, daß ich auch einfach mit »q« weiterkompilieren lassen kann, wenn die zitierte Fehlermeldung auftritt, dann nochmal normal kompilieren, und es paßt wieder. Oder über das Menü von TeXworks die Hilfsdateien löschen. Aber ich würde gerne verstehen, mit welchem Code-Schnipsel ich dieses seltsame Verhalten provoziere.

Und ich sollte wohl dazusagen, daß ich den Kompiliervorgang bei einem Syntaxfehler immer mit Strg-T abbreche, was wohl den Prozeß killt oder so. Aber das funktioniert normalerweise bestens.

Besserwisser

Beitrag von Besserwisser »

Wenn Du mit Strg-T abbrichst, dann wird der Prozess AFAIK tatsächlich gekillt. Dabei werden offene Dateien auch nicht korrekt beendet, sondern nur noch geschlossen. Die Inhalte der Hilfsdateien können dann fehlerhaft sein. Besser ist es, in der Konsoleeingabe (die kleine Zeile unten) bei einem Fehler ein x einzugeben. Zuvor kann es hilfreich sein, ein h einzugeben, um eventuell verfügbare zusätzliche Hilfe zu erhalten. Man kann auch ein r eingeben, damit der LaTeX-Lauf zwar fortgesetzt, aber bei weiteren Fehlern nicht mehr angehalten wird.

Mehr kann ich dazu nicht sagen, da Du leider die wichtigen Hinweise nicht beachtet hast. Neben dem dort angegebenen vollständigen Minimalbeispiel bräuchte man in diesem Fall vermutlich auch die aux-Datei, um näheres sagen zu können. Falls meine Erklärung und mein Hinweis oben Dir also nicht weiter helfen bzw. bei weiteren Fragen bitte ich das in Deinem eigenen Interesse zu beachten.

ehwlt
Forum-Anfänger
Forum-Anfänger
Beiträge: 37
Registriert: Sa 5. Mär 2011, 13:29

Beitrag von ehwlt »

Ein Minimalbeispiel zu geben gestaltet sich schwierig, da ich ja nicht weiß, wodurch der Fehler hervorgerufen wird. Ich hab inzwischen über 1300 Zeilen Code.

Ich habe gerade noch etwas rumprobiert und bin auf folgendes gestoßen. Die fehlerhafte aux-Datei sieht auszugweise so aus:
\relax 
\catcode`"\active
\select@language{german}
\@writefile{toc}{\select@language{german}}
\@writefile{lof}{\select@language{german}}
\@writefile{lot}{\select@language{german}}
\@writefile{toc}{\contentsline {chapter}{\numberline {1}Kapitel 1}{3}}
[…]
\@writefile{toc}{\contentsline {chapter}{\numberline {7}\IeC {\"U}
Das entsteht, wenn ich in einer abgesetzten Formel zum Beispiel das Makro \bla benutze, das nicht existiert. Wenn ich dann den Prozeß mit Strg-T kille, bleibt die aux-Datei natürlich so. Das passiert allerdings nur, wenn ich das \bla oder einen anderen Fehler nach einer bestimmten Code-Zeile in Kapitel 7 einfüge. Also auch dann, wenn ich ihn in Kapitel 8 reinschreibe. Füge ich den Fehler vor jener Zeile in Kapitel 7 ein und kompiliere, dann ist die aux-Datei leer, auch wenn sie vorher vollständig gefüllt war (wenn sie also schon existiert hat). Da ist es dann egal, ob ich den Prozeß mit Strg-T abwürge, die aux enthält dann ja keinen Fehler, weil sie leer ist.

In besagter Code-Zeile steht nichts besonderes, daher weiß ich noch nicht, wie ein Minimalbeispiel aussehen könnte. Der Fehler tritt auch auf, wenn ich die Zeile auskommentiere. Vielleicht habe ich später oder morgen die Zeit, das Dokument soweit einzudampfen, daß ich es als Beispiel posten kann.

Der momentane Kenntnisstand kurz zusammengefaßt: Wenn der Fehler weit genug hinten im Dokument auftritt, dann steht schon etwas in der aux-Datei drin, bis der Compiler auf den Fehler stößt. Die letzte Zeile der aux-Datei ist dann aber unvollständig und bleibt es auch, wenn man den Prozeß abwürgt, wodurch der nächste LaTeX-Lauf bei \begin{document} schon abbricht. Wenn der Fehler weiter vorne im Dokument steht, dann ist die aux-Datei beim Erreichen des Fehlers noch leer.

dknof
Forum-Anfänger
Forum-Anfänger
Beiträge: 48
Registriert: So 29. Jul 2012, 13:30

Beitrag von dknof »

Hallo ehwlt,

beim Kompilieren lässt sich auch einstellen, dass bei Fehlern nicht angehalten sondern übersprungen wird (wie das Drücken von „s“): -interaction nonstopmode
Bei Texmaker ist das die Standardeinstellung, die Fehler werden dann unter dem Quelltext angezeigt und per Mausklick kann man in die entsprechende Zeile springen. Schau mal, ob sich auch TeXworks entsprechend einstellen lässt. Dann hast Du die Fehlermeldungen und auch vollständige aux-Dateien.
Oder teste Texmaker aus, vielleicht sagt Dir der Editor zu.

Gruß
Diether

Noch so einer

Beitrag von Noch so einer »

Um es ganz deutlich zu sagen: Strg-T ist nur für Notfälle gedacht, wenn der Prozess aus irgendwelchen Gründen nicht ordentlich terminiert werden kann. Dass ist letztlich als würdest Du TeX über den Task-Manager abbrechen. Dass man dann mit defekten Dateien – sowohl Hilfsdateien als auch Ausgabedateien – endet, ist zu erwarten. Wie man TeX korrekt terminiert, wurde Dir bereits mitgeteit.

Bei TeXworks ist das interaktive Arbeiten der Normalfall. Es gibt dort AFAIK keine generelle Option in TeXworks selbst, um das zu ändern. Man kann aber natürlich jedem einzelnen TeX-Programm (also beispielsweise pdflatex) in den Einstellungen von TeXworks den Parameter -interaction=nonstopmode oder -halt-on-error mitgeben. Bei MiKTeX heißen die Parameter eventuell anders. Ggf. am besten in der Hilfe nachschauen.

TeXworks ist für mich allerdings ein LaTeX-Editor mit insgesamt wenig Komfort, den ich eher im Notfall verwenden würde, wenn nichts anderes zur Verfügung steht. Im Unterforum zu Editoren gibt es eine Liste in der sich auch komfortablere Werkzeuge finden lassen.

ehwlt
Forum-Anfänger
Forum-Anfänger
Beiträge: 37
Registriert: Sa 5. Mär 2011, 13:29

Beitrag von ehwlt »

TeXmaker und TeXmakerX hatte ich glaube ich schon mal beide ausprobiert. Damals haben die mir anscheinend nicht so zugesagt. Aber es stimmt, TeXworks ist auch nicht das gelbe vom Ei, jetzt probier ich nochmal eine Weile TeXstudio (also das damalige TeXmakerX).

Ich habe gerade einen ganz anderen Versuch gemacht: Wenn ich in dem Dokument keinen Fehler habe, mit TeXworks kompiliere und spät genug abwürge, dann bleibt auch eine unvollständige aux-Datei übrig. Es liegt also wahrscheinlich gar nicht am Code, sondern an der Länge des Dokuments. Die Erzeugung der aux-Datei dauert anscheinend so lange, daß die Datei bei kürzeren Dokumenten erst gefüllt wird, wenn bereits der gesamte Code eingelesen ist.

Besserwisser

Beitrag von Besserwisser »

Du willst es offenbar nicht kapieren oder bist Du einfach nur stur? Computerprogramme schreiben nicht jedes einzelne Byte gleich auf Platte. Würden sie das machen, wären sie schnarchlangsam, weil Platten nicht Byte-Weise, sondern Blockweise organisiert sind und darüber hinaus das Schreiben mehrerer Blöcke weit schneller geht als einzelner Blöcke. Also werden Daten im Speicher gesammelt, bevor sie geschrieben werden. Wenn dann genug zusammen gekommen ist, dann wird geschrieben (im Idealfall sogar asynchron). Schießt man nun ein Programm einfach ab, bevor es alle Daten geschrieben hat, bleiben immer defekte Daten übrig. Deshalb warnt der Taskmanager beispielsweise genau davor. TeXworks warnt nicht, sondern geht davon aus, dass der Anwender schon wissen wird, was er da tut.

Was Du machst ist, als würdest Du erst 1000g Mehl abmessen, dann aber während des Umschüttens in die Rührmaschine, die Maschine wegziehen und Dich dann beschweren, dass das Rezept nicht stimmt, weil im Teig nur 512g Mehl gelandet sind und der Rest irgendwo im Nirwana landet.

Merke: Schieße niemals Programme einfach ab, außer Du hast keine andere Wahl. Bei LaTeX hast Du das Glück, dass Du immerhin alles aus den Quellen wieder rekonstruieren kannst. Schon beim Editor kannst Du aber auf die Nase fliegen.

ehwlt
Forum-Anfänger
Forum-Anfänger
Beiträge: 37
Registriert: Sa 5. Mär 2011, 13:29

Beitrag von ehwlt »

Besserwisser hat geschrieben:Du willst es offenbar nicht kapieren oder bist Du einfach nur stur?
Den Ton brauch ich mir nicht bieten zu lassen. Ich hab sehr wohl kapiert, was ich da mit Strg-T »anrichte«. Aber du hast anscheinend mein Anliegen nicht begriffen. Ich benutze TeXworks seit Jahren in der beschriebenen Weise, und nie ist dieses Phänomen aufgetreten. Ich weiß sehr wohl, daß Programme ihr Zeug nicht gleich auf Platte schreiben. Aber wann sie es tun, das bleibt dann doch dem Programmierer überlassen. Und ich wußte nicht, daß pdflatex noch während des Kompiliervorgangs anfängt, die aux-Datei zu füllen. Die Beobachtung, daß es immer den gleichen Inhalt in diese Datei schrieb, egal wo der Fehler lag, also egal wo der Kompiliervorgang unterbrochen wurde, ließ ja wohl die Vermutung zu, daß es vielleicht nicht am Prozeßabbruch lag, sondern am Quelltext.

Noch so einer

Beitrag von Noch so einer »

ehwlt hat geschrieben:Die Beobachtung, daß es immer den gleichen Inhalt in diese Datei schrieb, egal wo der Fehler lag, also egal wo der Kompiliervorgang unterbrochen wurde, ließ ja wohl die Vermutung zu, daß es vielleicht nicht am Prozeßabbruch lag, sondern am Quelltext.
Es ist keineswegs egal, wo TeX gekillt wird. Aber da die aux-Datei stückweise geschrieben wird, hängt gibt es natürlich mehrere mögliche Punkte, die zu demselben defekten Ergebnis führen. Wenn das vorher auch mal funktioniert hat, dann war das Zufall und zwar einer, der nach den ganzen Erklärungen eigentlich für jeden zu verstehen sein sollte. Aber wenn Du schon glaubst, dass es doch am Quelltext liegen könnte, warum folgst Du dann nicht dem Link, den Dir Besserwisser extra angegeben hat, und beachtest, was dort steht?

Ich muss das jetzt mal ganz deutlich sagen: Du verhältst Dich schon etwas seltsam. Angeblich hast Du im Nachhinein bereits alles gewusst, wunderst Dich aber trotzdem über Ergebnisse, die absolut zu erwarten waren, Du verharrst in deiner Fehlbedienung und wunderst Dich auch noch, wenn nach mehrmaligen Hinweisen, was Du da falsch machst und wie man es richtig macht, jemand irritiert ist oder auch einmal die Geduld verliert.

Statt Dich zu beschweren und immer weiter auf einer Fehlbedienung zu beharren, solltest Du lieber einmal die Kritik annehmen und Dich außerdem bei Besserwisser und dknof bedanken, dass sie Dir ziemlich schnell absolut korrekter Antworten und Lösungen geliefert haben.

@Moderator: Ich glaube, es ist an der Zeit, diese Diskussion zu beenden.

Besserwisser

Beitrag von Besserwisser »

ehwlt, Du glaubst also tatsächlich noch immer, dass das Problem nicht an Deinem falsch eingesetzten Strg-T liegt, sondern seine Ursache im Quelltext, den Du uns trotz ausdrücklicher Nachfrage verheimlichst, zu suchen ist? Du beharrst darauf, obwohl Dir mehrfach erklärt wurde, dass und sogar warum das Strg-T zu dem Problem führt?

Wie würdest Du ein solches Verhalten beurteilen, wenn es nicht Deines wäre, sondern Du als Hilfeleistender damit konfrontiert würdest? Nein, ich will tatsächlich keine Antwort auf diese rein rhetorische Frage. Mir wäre es weit lieber, wenn Du stattdessen einfach nur darüber nachdenken würdest. Ich glaube, das wäre zumindest auf längere Sicht besser.

Ich habe mir nun wirklich große Mühe für eine gemäßigte Reaktion gegeben und in der letzten dreiviertel Stunde meine Antwort mehrfach geändert, gelöscht, neu geschrieben. Ich hoffe, Du regst Dich nun nicht schon wieder auf, sondern lernst wirklich etwas aus den Antworten, die Du bekommen hast. Tatsächlich wollte ich Dich wachrütteln und nicht beleidigen.

Gesperrt