Diskussion zu: "Tip: Fehlersuche"

[The EYE]

Hallo!
Könnte man nicht auf \input{*.tex} ausweichen? ggf in Kombination mit % davor?

Gruß Max

P.S.: Dazu möchte ich sagen, dass es irgendwann natürlich zu umständlich werden würde...

[Xenara]

Aufgrund dieses Threads (insbesondere ab Beitrag Nr. 13) rege ich an, eine Anmerkung zu den Tücken von \include einzufügen. Ich bin mir zwar nicht sicher, wie oft dieser Befehl problematische Nebenwirkungen hat, aber aufgrund des Hinweises von Ulrike Fischer kann man durchaus auf \include verzichten.

Die Formulierung könnte etwa so lauten (Verbesserungsvorschläge erwünscht!): "Falls du Dateien mittels \include einbindest: Tritt der Fehler auch auf, wenn du die entsprechenden Textteile direkt in dein Hauptdokument einbindest?"

lockstep

Danke für den Hinweis. Ich werde versuchen, es in den Teil "Vom Dokument zum Minimalbeispiel" einzubauen, es fehlt nämlich tatsächlich noch ein Hinweis darauf, wie mit solchen inputs/includes umgegangen werden soll (unabhängig davon, ob sie der Fehler sind). Ich denke, dort kann man deinen Vorschlag gut unterbringen.

Dass include Probleme machen kann, wusste ich bisher noch nicht.
Soweit ich verstanden habe, ist input nur eine "Umleitung" im Code, während include auf einer neuen Seite anfängt und .aux-Dateien erzeugt.
Weshalb und in welchen Fällen kann es da zu Problemen mit include kommen? Wo liegen genau die Unterschiede? Das wäre für mich interessant zu wissen, damit ich den Text entsprechend korrekt anpassen kann.

[LuPi]

Diese Diskussion wurde schon verschiedentlich geführt, beispielsweise hier:
http://www.wer-weiss-was.de/theme155...le3325219.html

Vielleicht kannst Du da wesentliche Argumente übernehmen?

Für mich als Nicht-Guru bestehen die Unterschiede im Wesentlichen darin,
dass ich (a) \input's schachteln kann (im Gegensatz zu \include), (b) \include's immer eine neue Seite beginnen und (c) mir \include die Möglichkeit eines selektiven Vorgehens mittels \includeonly erlaubt.

[BeniBela]

Es gibt anscheinend auch Unterschiede, ob die Logdatei zuverlässig von einem Programm ausgewertet werden kann, so dass auch alle gemeldeten Fehler der richtigen Datei zugeordnet werden.
Zumindest steht im Kile-Quellcode, dass man nicht \input, sondern entweder \Input (wohl noch eine dritte Variante) oder \include verwenden sollte.

[voss]

Es gibt anscheinend auch Unterschiede, ob die Logdatei zuverlässig von einem Programm ausgewertet werden kann, so dass auch alle gemeldeten Fehler der richtigen Datei zugeordnet werden.
Zumindest steht im Kile-Quellcode, dass man nicht \input, sondern entweder \Input (wohl noch eine dritte Variante) oder \include verwenden sollte.

Es gibt in LaTeX \include{Datei} und \input{Datei} und es gibt in
TeX \input Datei

Und die Fehldermeldungen sind eindeutig! Wenn GUIs zu blöd sind,
diese richtig zu interpretieren, dann sollte man eine andere wähken.

Herbert

[voss]

Dass include Probleme machen kann, wusste ich bisher noch nicht.
Soweit ich verstanden habe, ist input nur eine "Umleitung" im Code, während include auf einer neuen Seite anfängt und .aux-Dateien erzeugt.
Weshalb und in welchen Fällen kann es da zu Problemen mit include kommen? Wo liegen genau die Unterschiede? Das wäre für mich interessant zu wissen, damit ich den Text entsprechend korrekt anpassen kann.

Wieso soll \include Probleme machen?

Herbert

[BeniBela]

Es gibt in LaTeX \include{Datei} und \input{Datei} und es gibt in
TeX \input Datei

Und \Input aus srcltx.sty

Und die Fehldermeldungen sind eindeutig! Wenn GUIs zu blöd sind,
diese richtig zu interpretieren, dann sollte man eine andere wähken.

Das Problem sind wohl die Dateinamen. Bei \input schreibt TeX bei einer neuen Datei im Log "(dateiname" und nachdem alle Fehler in dieser Datei ausgegeben wurden, fährt es nach der Ausgabe einer schließende Klammer mit den Fehlern in der Datei mit dem \input fort.
Wenn die fehlerhafte Dokumentstelle jetzt aber eine ) enthält, gibt es im Log zu viele schließende Klammern und es ist nicht eindeutig, welche Klammer zum Text und welche zum Log gehört.

[voss]

Und \Input aus srcltx.sty

für LaTeX uninteressant ...

Das Problem sind wohl die Dateinamen. Bei \input schreibt TeX bei einer neuen Datei im Log "(dateiname" und nachdem alle Fehler in dieser Datei ausgegeben wurden, fährt es nach der Ausgabe einer schließende Klammer mit den Fehlern in der Datei mit dem \input fort.
Wenn die fehlerhafte Dokumentstelle jetzt aber eine ) enthält, gibt es im Log zu viele schließende Klammern und es ist nicht eindeutig, welche Klammer zum Text und welche zum Log gehört.

es bleibt trotzdem ein Problem der GUIs und nicht LaTeX, dass sie
das nicht vernünftig scannen können.

Herbert

[Xenara]

Aufgrund dieses Threads (insbesondere ab Beitrag Nr. 13) rege ich an, eine Anmerkung zu den Tücken von \include einzufügen. Ich bin mir zwar nicht sicher, wie oft dieser Befehl problematische Nebenwirkungen hat, aber aufgrund des Hinweises von Ulrike Fischer kann man durchaus auf \include verzichten.

Die Formulierung könnte etwa so lauten (Verbesserungsvorschläge erwünscht!): "Falls du Dateien mittels \include einbindest: Tritt der Fehler auch auf, wenn du die entsprechenden Textteile direkt in dein Hauptdokument einbindest?"

Die Anregungen zu input/include sind jetzt in der Anleitung unter "Vom Dokument zum Minimalbeispiel - Variante 1" -> Absatz "6." eingefügt.
Auf Erklärungen zu input/include habe ich verzichtet, da der Beitrag ja "nur" eine Anleitung sein soll, die Probleme einzugrenzen und ein Minimalbeispiel zu erstellen.

[tral]

Hallo,

mir ist gerade aufgefallen, dass es durch das Auskommentieren zu Missverständnissen kommen kann:

Z.B. hat jemand ein langes Dokument und kommentiert darin aus, um ein Minimalbesipiel zu erstellen. Anschließend kopiert er das in eine CODE-Umgebung und löscht dabei alle Kommentare, da die ja niemanden etwas angehen.

Das Problem daran ist, dass jetzt die Zeilenzähler der beiden Dokumente (MB mit und ohne Kommentare) verschieden sind, also z.B. log-Ausgaben nicht mehr so richtig verglichen werden können.

Vielleicht sollte das in der Anleitung zum Minimalbeispiel klarer gemacht werden...

Christian.

PS. Ach ja, fast vergessen

\documentclass{article}

%\usepackage{usefulstuff}
\begin{document}
TEST \wrongCommand
\end{document}

führt zu:

! Undefined control sequence.
l.5 TEST \wrongCommand

, wohingegen

\documentclass{article}

\begin{document}
TEST \wrongCommand
\end{document}

ergibt:

! Undefined control sequence.
l.4 TEST \wrongCommand

[bischi]

Du musst halt die zum Beispiel passende Log-Datei mitposten - dann gibts auch kein Problem

MfG Bischi

[tral]

Du musst halt die zum Beispiel passende Log-Datei mitposten - dann gibts auch kein Problem

MfG Bischi

Doch! Ich poste meine log-Datei (Fehler in Zeile 5) und gebe aber die verkürzte Version als MB an. Dann ist es schwer, beim Testen des MB (Fehler in Zeile 4), dies in Übereinstimmung mit dem log-File zu bekommen!

Christian.

[Xenara]

Aber du testest doch das verkürzte MB nochmal, bevor du es ins Forum stellst. Du willst ja sichergehen, dass nicht versehentlich zu viel oder das Falsche gelöscht wurde, und ob der Fehler in genau diesem Code noch reproduzierbar ist.
Und du postest die zum _MB_ gehörende log-Datei, die bei dir entsteht und per Definition das Problem noch immer aufweist. Dann passts doch wieder.

Zitat aus dem Fehlersuche-Beitrag:

Das fertige MB kompilierst Du dann und überprüfst, ob das Ergebnis (z.B. die Fehlermeldung) tatsächlich noch das gleiche ist wie beim Ausgangsdokument.
Und dann stellst Du diesen Code als Minimalbeispiel mit einer kurzen, aussagekräftigen Erklärung hier ins Forum.

Wenn der Fehler im MB gefunden ist, musst du sowieso die entsprechende Stelle im Ursprungsdokument finden und korrigieren.

[voss]

Doch! Ich poste meine log-Datei (Fehler in Zeile 5) und gebe aber die verkürzte Version als MB an. Dann ist es schwer, beim Testen des MB (Fehler in Zeile 4), dies in Übereinstimmung mit dem log-File zu bekommen!

Du gibst das Logfile passend zum MB an, sonst kannst du
dir auch alles sparen und Kommentare in einem Minimalbeispiel
sind nur dann von Interesse, wenn sie den Tester etwas zu sagen
haben.

Herbert

[tral]

Du gibst das Logfile passend zum MB an, sonst kannst du
dir auch alles sparen und Kommentare in einem Minimalbeispiel
sind nur dann von Interesse, wenn sie den Tester etwas zu sagen
haben.

Herbert

Ja, mir ist das schon klar. Aber ich glaube, halt anderen nicht. Und dann kann es zu Missverständnissen kommen. Siehe z.B. hier: http://www.mrunix.de/forums/showpost...58&postcount=3 und meine Antwort...

War ja nur eine Anregung, das klar zu stellen...

Christian.