如何使用 exex(go) 在 linux/macOS 中正确模拟终端？

Question

我需要在go. 我尝试这样做：lsCmd := exec.Command("bash", "-c", "ls")lsOut, err := lsCmd.Output()if err != nil {    panic(err)}fmt.Println(string(lsOut))而且它似乎工作正常（本机 ubuntu 终端显示一个水平列表，这个函数的结果是垂直的）。但是，如果我专门调用了错误的命令，例如exec.Command ("bash", "-c", "lss")，我会得到：恐慌：退出状态 127在本机 ubuntu 终端中，我得到以下结果：找不到命令“lss”，您的意思是：和命令的枚举。如果我在标准 ubuntu 终端中编写命令，我需要与本机终端通信，并得到与命令结果相同的结果。做这个的最好方式是什么？也许exec图书馆不适合这个？所有这些对于与 OS 终端的前端通信都是必需的。在一个简单的html/css/js页面上，用户输入一个命令，然后go将其发送到操作系统的本机终端，并将结果返回给前端。如何获得与在本机终端中工作一样的执行命令结果？

Answer 1

问题

但是，如果我专门调用了错误的命令，例如 exec.Command ("bash", "-c", "lss")，我会得到：

panic: exit status 127

在本机 ubuntu 终端中，我得到以下结果：

Command 'lss' not found, did you mean:

和命令的枚举。

这与 Go 无关，问题实际上有两个方面：

• Ubuntu 附带一个特殊的包，command-not-found通常是预先安装的，它通过使用两种技术来尝试使终端对普通人更友好：

• 它试图建议更正拼写错误（您的情况）。

• 当用户尝试执行一个程序时，它会尝试建议要安装的软件包，如果用户安装了特定的软件包，该程序将可用。

• 当找不到该命令时，“plain”（见下文）shell 通过返回非零退出代码使尝试失败。
  这是完全可以预料和正常的。我的意思是，对此感到恐慌是绝对不明智的。

• 在 Unix 系统上运行 shell 的方式存在历史差异。

  当用户登录系统时（请记住，在发明外壳概念的日子里，您将通过硬件计算机终端登录，这基本上是您的 GNOME 终端窗口，但在硬件中，并通过电线连接)，即启动所谓的登录shell。
  逻辑外壳的主要思想是为用户提供交互环境。

  但是您肯定知道，shell 也能够执行脚本。当 shell 执行脚本时，它以非交互模式运行。

Unix shell 可以工作的模式

现在让我们更深入地研究交互式与非交互式 shell。

• 在交互模式下：

• shell 通常连接到真实终端（hadrware 或终端仿真器；您的 GNOME 终端窗口是终端仿真器）。
  “已连接”是指将shell 的标准I/O 流连接到终端，以便终端显示shell 打印的内容。

• 它为用户启用了某些花里胡哨，通常提供有限的方法来编辑正在输入的内容（bash例如，使用 GNUreadline .

• 在非交互模式下：

• shell 的标准 I/O 流连接到一些文件（或“无处”——比如/dev/null）。

• 没有启用任何花里胡哨的功能——因为没有人可以使用它们。

GNUbash能够在这两种模式下运行，它运行在哪种模式下取决于它是如何被调用的。

在不同的模式下初始化时，bash 读取不同的初始化脚本，这就解释了为什么command-not-found包提供的机器会进入交互模式，而在其他情况下运行 bash 时不会——就像你从 Go 调用一样。

遇到问题怎么办

最简单的尝试是使用--login命令行选项运行 bash，或者让它认为它作为交互式 shell 运行。

这可能会解决您的问题，但不一定。
下一个可能的问题是，有些程序确实会检查它们是否在终端上运行——通常这些程序坚持与用户进行真正的交互，通常是出于安全目的，有些程序在未连接到终端时根本无法运行一个真正的终端——这些是“全屏”文本 UI 程序，例如 GNU Midnight Commander、Vim、Emacs、GNU Nano 和类似的任何东西。

要解决这个问题，唯一的解决方案是在伪终端环境中运行 shell，这就是 @eudore 在他们的评论中暗示的。可能是一个开始查看的包
；还提供了一些方法来纠缠 PTY。github.com/creack/ptygolang.org/x/crypto/ssh