Ruby 生成进程，捕获 STDOUT/STDERR，同时表现得好像它是定期生成的

Question

我想要达到的目标：

• 从 Ruby 进程生成子进程
• 子进程应正常打印回终端。 “正常”是指该过程不应错过颜色输出，或忽略用户输入 (STDIN)。
• 对于该子流程，捕获 STDOUT/STDERR（联合）例如到子进程死亡后可以访问的字符串变量。转义字符等等。

通过传递不同的 IO 管道可以捕获 STDOUT/STDERR，但是子进程可以检测到它不在 tty 中。例如git log 不会打印影响文本颜色的字符，也不会使用它的寻呼机。

使用pty 启动进程本质上是“欺骗”子进程，使其认为它是由用户启动的。据我所知，这正是我想要的，结果基本上符合所有条件。

我测试解决方案是否符合我的需求的一般测试是：

• ls -al 是否正常运行？
• vim 是否正常运行？
• irb 是否正常运行？

以下 Ruby 代码可以检查以上所有内容：

to_execute = "vim"

output = ""
require 'pty'
require 'io/console'

master, slave = PTY.open
slave.raw!

pid = ::Process.spawn(to_execute, :in => STDIN, [:out, :err] => slave)
slave.close
master.winsize = $stdout.winsize
Signal.trap(:WINCH) { master.winsize = $stdout.winsize }
Signal.trap(:SIGINT) { ::Process.kill("INT", pid) }

master.each_char do |char|
  STDOUT.print char
  output.concat(char)
end

::Process.wait(pid)
master.close

这在大多数情况下都有效，但事实证明它并不完美。出于某种原因，某些应用程序似乎无法切换到raw 状态。尽管vim 工作得很好，但结果证明neovim 没有。起初我认为这是 neovim 中的一个错误，但后来我能够使用 Rust 语言的 Termion crate 重现该问题。

通过在执行前手动设置为 raw (IO.console.raw!)，neovim 之类的应用程序的行为符合预期，但irb 之类的应用程序则不然。

奇怪地在 Python 中生成 另一个 pty，在这个 pty 内，允许应用程序按预期工作（使用 python -c 'import pty; pty.spawn("/usr/local/bin/nvim")'）。这显然不是一个真正的解决方案，但仍然很有趣。

对于我的实际问题，我想我正在寻求任何帮助来解决奇怪的raw 问题，或者说如果我完全误解了 tty/pty，我应该在哪里/如何看待问题的任何不同方向.

Answer 1

[已编辑：修改后的更新见底部]

想通了:)

为了真正理解这个问题，我阅读了很多关于 PTY 是如何工作的。在我把它画出来之前，我认为我并没有真正理解它。基本上 PTY 可以用于终端模拟器，这是考虑它的数据流的最简单方法：

keyboard -> OS -> terminal -> master pty -> termios -> slave pty -> shell
                                               |
                                               v
 monitor <- OS <- terminal <- master pty <- termios

（注意：这可能不是100%正确，我绝对不是这方面的专家，只是发布它以帮助其他人理解它）

所以图表中我没有真正意识到的重要一点是，当您键入时，您在屏幕上看到输入的唯一原因是因为它被传递返回（向左）主人。

所以第一件事是第一件事 - 这个 ruby​​ 脚本应该首先将 tty 设置为 raw (IO.console.raw!)，它可以在执行完成后恢复它 (IO.console.cooked!)。这将确保此父 Ruby 脚本不会打印键盘输入。

第二件事是从机本身不应该是原始的，因此删除了slave.raw! 调用。为了解释这一点，我最初添加了这个，因为它从输出中删除了额外的回车：运行echo hello 导致"hello\r\n"。我错过的是这个回车是终端模拟器的关键指令（哎呀）。

第三件事，进程应该只与从机对话。传递STDIN 感觉很方便，但它扰乱了图中所示的流程。

这带来了一个关于如何传递用户输入的新问题，所以我尝试了这个。所以我们基本上将STDIN 传递给master：

  input_thread = Thread.new do
    STDIN.each_char do |char|
      master.putc(char) rescue nil
    end
  end

有点有效，但它有其自身的问题，即某些交互过程有时没有收到密钥。时间会证明一切，但使用 IO.copy_stream 似乎可以解决这个问题（当然读起来更好）。

input_thread = Thread.new { IO.copy_stream(STDIN, master) }

---

8 月 21 日更新：

所以上面的例子大部分都有效，但由于某些原因，像 CTRL+c 这样的键仍然不能正常工作。我什至查看other people's approach 看看我可能做错了什么，实际上它似乎是相同的方法 - 因为IO.copy_stream(STDIN, master) 成功地将3 发送给主人。以下似乎都没有帮助：

master.putc 3
master.putc "\x03"
master.putc "\003"

在我开始尝试用较低级别的语言实现这一目标之前，我又尝试了 1 件事——块语法。显然块语法神奇地解决了这个问题。

为防止此答案过于冗长，以下似乎可行：

require 'pty'
require 'io/console'

def run
  output = ""

  IO.console.raw!

  input_thread = nil

  PTY.spawn('bash') do |read, write, pid|
    Signal.trap(:WINCH) { write.winsize = STDOUT.winsize }
    input_thread = Thread.new { IO.copy_stream(STDIN, write) }

    read.each_char do |char|
      STDOUT.print char
      output.concat(char)
    end

    Process.wait(pid)
  end

  input_thread.kill if input_thread

  IO.console.cooked!
end

Bundler.send(:with_env, Bundler.clean_env) do
  run
end