我正在尝试编写与 GDB 交互的测试，但在捕获输出时遇到问题。我希望生成一个日志文件，它看起来就像手动执行测试时在终端中看到的那样。然而事实证明，GDB 在捕获其输出方面非常顽固。
我已经能够编写 Expect 脚本，这些脚本能够与 GDB 交互，并且其输出可以重定向到日志文件，但我不想在 TCL 中编写测试。我希望使用与 Java 兼容的 Groovy。由于某种原因，Perl 的 Expect 和 ExpectJ 程序输出总是转到终端并且无法重定向到文件。
我尝试使用 ProcessBuilder 从 Java 启动 GDB 进程，它基本上可以工作，但 print 语句的输出永远不会出现在 stdout 上并且无法捕获。我想如果 Expect 有效，那么我会从 Java 启动 Expect 并让它与 GDB 交互，但在这种情况下，大部分程序输出都会丢失，永远不会出现在创建的进程的标准输出中。
所以我的问题是，如何在 Groovy(Java 也可以)中编写一个与 GDB 交互并捕获所有输出的测试？
伪代码:
process = "gdb -q".execute()
waitForPrompt()
send("file exec")
waitForPrompt()
send("run")
send("quit")
日志文件:
(gdb) file exec
Reading symbols from exec...done.
(gdb) run
Starting program: exec
<... output ...>
Program exited normally.
(gdb) quit
最佳答案
一种可能性是 GDB 输出在标准错误上转储，而您仅捕获标准输出。您应该能够通过重定向来解决此问题，我认为是这样的:
process = "gdb -q 2&>1".execute()
第二个猜测是，可能值得检查“显示交互模式”在工作和非工作情况下的含义。如果它们不同，请在执行其他操作之前尝试“设置交互模式关闭”。
第三种选择是使用 GDB 的日志记录工具来写入日志文件(“设置日志记录文件”和“设置日志记录”)并避免自己捕获输出。
关于java - 使用 GDB 编写测试 - 如何捕获输出？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2321087/