我是一个命令行迷，经常用pdflatex filename.tex终端上的简单命令进行编译，我忘记（或太懒）输入-interaction=nonstopmode或interaction=batchmode。因此，当我遇到错误时，我会给出交互式提示，我发现这很令人困惑和不直观，并且通常使用 'q' 尽快退出。
是否有人使用过交互式提示，并且发现它们比简单地解析 .log 文件、修复问题并从头开始重新编译更有用或更有优势？交互式系统值得学习吗？
如果一定要我猜的话，我认为交互模式自 TeX 早期以来就没有发生过太大的变化，那时更久，更长编译文档，并且您可能不想因为犯了一个小错误而从头开始。但是既然编译最多只需几秒钟，那么还有什么令人信服的理由使用交互模式吗？
我之所以问这个问题，部分原因是我即将投入alias pdflatex='pdflatex -interaction=batchmode'使用.bashrc，但我想知道是否有人认为我这样做会失去什么。如果是这样，有没有关于如何使用交互式系统的免费文档？（或者我是不是想太多了/把它复杂化了？）
答案1
我也认为，当编辑-编译-测试周期很长并且人们无法承受每次错误都重新开始时，交互模式非常重要。
然而，如今我们更习惯于 Unix 风格的错误报告，其中实用程序会打印错误并立即退出。幸运的是，有一个命令行开关组合可以做到这一点：
pdflatex -interaction=nonstopmode -halt-on-error
使用此命令行，只会在终端上打印第一个错误，并将控制权返回给 shell。唯一的缺点是您无法再键入任何内容H来阅读错误帮助 — 但如果您至少有一些使用 LaTeX 的经验，那么您就不需要经常使用错误帮助文本。
答案2
我有时使用交互模式进行调试。您可以I在提示中使用来插入代码。然后我经常写\makeatletter\show\@some@internal@macro或类似的东西。这\show将为您带来另一个提示，并且可以再次使用I它来添加更多代码。我发现如果只做一次，这比将此调试代码放入文档中更快。否则，您必须中止，编辑代码，编译并再次更改代码。
我对代码的任何实际修复都是在原始文件中进行的，而不是在交互模式下，否则它就会丢失。
请注意，您可以定义别名（Unix/Linux）或 Shell/Batch 脚本来调用pdflatex或nonstopmode。batchmode我还使用 Raphink 提到的 Makefile。也latexmk非常有用（需要-pdfPDF 输出选项）。最后，还有\nonstopmode和\batchmode宏（实际上是原语），它们可用于在文档中更改为该模式。
答案3
我通常不会像您那样设置别名，而是为项目编写一个 Makefile，内容如下：
TEXINPUTS=microtype:
%.pdf: %.tex
TEXINPUTS=$(TEXINPUTS) xelatex -shell-escape -interaction=batchmode $*
TEXINPUTS=$(TEXINPUTS) xelatex -shell-escape -interaction=batchmode $*
所以我只需输入代码make mydocument.pdf即可构建 PDF。每当我遇到错误时，我都喜欢重新启动命令，而无需执行该操作，-interaction=batchmode这样它就会以交互方式停止，我可以准确地看到代码失败的位置。我不使用交互式控制台本身不过，X大多数时候我只是按一下。
答案4
如果正在处理的文件中只有一个错误，则批处理方法可能是合适的。但是，如果有多个错误，则使用交互式方法可以以交互方式更正错误并继续，查找其他错误，并可能更正它们，以便完成作业。（一个典型的错误是命令名称的拼写错误；通常一个简单的内联\let或定义将处理同一错误的多个实例。）然后返回，修复日志中报告的内容（确保检查导致您输入交互式解决方法的任何拼写错误的多个实例），然后您就可以开始了。
如果出现真正致命的错误，即一个错误会触发许多其他错误，并且无法简单地在线纠正，那么就该退出，返回日志，修复已知问题并重新启动。在包含大量数学运算的文档中，这个过程比艰难地浏览“不完整”的日志（报告了太多错误后 tex 会退出）和以批处理模式进行迭代要简单和快捷得多。事实上，当前的编译速度使这种方法比过去乌龟速度机器的糟糕时代更有吸引力。
一旦文件清理干净，批处理模式适合多次运行以生成良好的引用链接和最终索引和目录。
我也是命令行迷，因此这不是一个相关的考虑。