将 stderr 恐慌重定向回 go 中的终端

Golang不知道大家是否熟悉？今天我将给大家介绍《将 stderr 恐慌重定向回 go 中的终端》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

我正在尝试使用以下 go 代码将恐慌/标准错误重定向回 bash 终端：

if err := syscall.Dup2(-1,int(os.Stderr.Fd())); err != nil {
      log.Fatalf("Failed to redirect stderr to bash: %v",err)
    }

但是错误给了我一个“错误的文件描述符”，可能是因为我在第一个参数中使用了 -1 。我选择值 -1 是因为我发现 int(file.(*os.file).fd()) 在调用 file.close() 时返回 -1 。

至于我正在尝试做什么。在程序的其他地方，我调用了 syscall.dup2(int(file.fd()), int(os.stderr.fd()))，它将 stderr 记录到外部文件。但我希望 stderr 有时指向 bash 终端。

https://golang.org/pkg/syscall/ 没有给出 syscall.dup2 的详细解释。我开始研究 file.fd() 返回什么以及它是如何使用的，但也没有完全理解。

谁能告诉我如何将 stderr 重定向回 bash 终端？

解决方案

在用第一个 Dup2 覆盖原始 stderr 之前，您必须将其保存在某处。 （一般来说，使用 Dup2 功能关闭目标是一个坏主意，因为它无法报告错误。）然后您可以将 Dup2 that 返回到 int(os.Stderr.Fd( ))（又名 2）。

一般来说，这是不可能的，因为 Unix 程序可以在没有任何终端的情况下启动（或运行）。例如，它可以由 crontab(5) 作业启动，或者通过一些 at 或 ssh 命令等启动。还可以考虑您的程序与 redirections 或在 pipeline 中运行，或者您的程序在服务器中运行（例如在数据内部）中心）;那么它很可能没有任何终端。

常见的做法是程序的用户可能会将 stderr 重定向（可能不到终端，但更有可能重定向到某个文件）。您的用户将使用其 shell 来实现此目的（例如，运行 yyourprogram 2> /tmp/errorfile；读取 documentation of bash about redirections）

Terminals 是相当复杂的东西。您可以阅读TTY demystified页面。另请参阅 pty(7) 和 termios(3)。处理终端（在 Unix 上）的常用方法是使用 ncurses 库（在 Go 中已包装为 goncurses）。

这确实是个坏主意。您的用户希望他/她的 stderr 保持不变（如果需要的话，会在他/她的 shell 中重定向 stderr ）。按照惯例，您不应该在程序中弄乱 standard streams（并保留它们的原样）。

file descriptor 是一些小的正或零索引（进入 process 的文件描述符表）。像 dup2(2) 这样的系统调用需要有效的文件描述符，而 Go 的 syscall.Dup2 只是包装了 dup2(2)。

在 Linux 上，您可以通过查看 /proc/1234/fd/ 目录来查询 pid 1234 的某个进程的文件描述符表。更多信息请参阅 proc(5)。

如果您绝对确定您的程序正在在终端中运行，您可以打开 /dev/tty 来获取它。更多信息请参见tty(4)。但是，我不建议这样做（因为您最好将程序设计为可在任何终端外部运行）。

您可能想阅读一些Linux编程书籍，例如ALP。

为了记录目的，Go 提供了它的 log 包。另请参阅 Go 的 syslog(3) 和 log/syslog 包。

PS。我不了解Windows，但我相信它也可以在没有任何终端的情况下启动程序，例如作为 background process。因此，即使在 Windows 上，我也会尽量避免这样做（将 stderr 重定向到终端）。

终于介绍完啦！小伙伴们，这篇关于《将 stderr 恐慌重定向回 go 中的终端》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！