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 箱重现该问题。

通过在执行前手动设置为 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.raw!)。煮熟了!)。这将确保此父 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

这种有点有效，但它有自己的问题，因为某些交互进程有时没有收到 key 。时间会证明一切，但使用 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"

在我深入研究尝试用较低级别的语言实现这一目标之前，我又尝试了一种东西 - block 语法。显然， block 语法神奇地解决了这个问题。

为了防止这个答案变得过于冗长，以下方法似乎有效:

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