之前，我错误地将我的专栏命名为 “SIGALRM 定时器和 Stdin 分析”。 结果表明，当我完成写作时，我花了很多时间谈论 SIGALRM 以及如何设置定时器以避免脚本永远挂起，但我实际上从未触及 stdin 分析的主题。 哎呀。

那么这次，让我们从这个主题开始。 这里要模拟的行为是许多实用程序都在做的事情，而您却没有太注意：如果它们的输入或输出是管道或文件，它们的行为与输入或输出是 stdin（键盘）或 stdout（屏幕）时的行为不同。 尝试 ls 与 ls|cat 来看看我的意思。

test 命令在这方面有一个有用的标志：-t。 来自手册页

True if the file whose file descriptor number is
file_descriptor is open and is associated with a terminal.

值得注意的是，文件描述符 #0 是 stdin； #1 是 stdout，#2 是 stderr（分别发音为“标准输入”、“标准输出”和“标准错误”）。 这就是为什么使用 >& 通过文件描述符重定向适用于 2>&1 以使错误消息像常规输出消息一样转到 stdout 的原因。

回到主题——在实践中，-t 测试可以像这样使用

#!/bin/sh
if [ -t 0 ]; then
  echo script running interactively
else
  echo stdin coming from a pipe or file
fi

这很容易测试

$ sh inter.sh
script running interactively
$ sh inter.sh < inter.sh
stdin coming from a pipe or file
$ cat inter.sh | sh inter.sh
stdin coming from a pipe or file

完美。 现在，如何识别输出是否是交互式终端、文件或管道？ 事实证明，您可以使用相同的基本测试，只需将文件 ID 0 替换为 #1

if [ -t 1 ] ; then
  echo output going to the screen
else
  echo output redirected to a file or pipe
fi

结果

$ sh inter.sh
script running interactively
output going to the screen
$ sh inter.sh | cat
script running interactively
output redirected to a file or pipe
$ sh inter.sh > output.txt
$ cat output.txt
script running interactively
output redirected to a file or pipe

非常酷，实际上。

让我们稍微回顾一下，在离开这个主题之前再看一下文件重定向。

我已经谈到了将 stderr 重定向到 stdout 的常用技巧 2>&1——这在命令行上非常有用。 您还可以将 shell 脚本中特定行的输出重定向到 stderr，这样即使 stdout 被发送到管道或文件，您的错误消息也会发送到屏幕

echo Error: this is an error message >&2

但是，如果您想让您的脚本强制 stdout 到特定目标，而不管有人在命令行上做什么，该怎么办？ 这是可以做到的——当然——尽管它涉及一种非常不同的方法：使用 exec 命令。

在最基本的情况下，exec 调用就像一个子 shell 调用（这实际上是每次您调用任何系统命令（如 ls 或 fmt）时发生的事情），但它是现有 shell 被指定的命令替换，从而有效地终止当前进程。 例如，如果您有一个 shell 脚本为外部调用设置了特定参数，您可以以以下内容结束它

exec $cmd $args

并且您在原始脚本中该点之后可能拥有的任何内容都将被抛弃，因为脚本不再运行，它被 $command 替换。

但是 exec 实际上比这更细致，特别是，它的行为的一个怪癖给出了我们寻求的解决方案：exec 将 stdin、stdout 和 stderr 的所有当前分配替换为在调用中指定的分配。

这就是解决方案，将 stdout 重定向到一个文件

exec > output.txt

在实践中，您可以通过此代码片段了解它的工作原理

echo This is stdout
exec > output.txt
echo This is still stdout but goes elsewhere

让我们实际上将一些不同的东西放在这个脚本中，这样您就可以看到这一切是如何协同工作的

echo this goes to stdout
echo and this goes to stderr >&2
exec > output.txt
echo This is still stdout but goes elsewhere
echo but where does this go\? >&2
exec date
echo this script is kaput

这是您运行程序时发生的情况

$ sh test.sh
this goes to stdout
and this goes to stderr
but where does this go?

但是，output.txt 中实际上有什么？

$ cat output.txt

这仍然是 stdout，但它去了其他地方

Sun Oct  7 10:29:56 MDT 2012

有趣。 请注意，正如预期的那样，“this script is kaput”永远不会显示出来，因为一旦 exec 调用外部程序（在本例中为 date），脚本本身就完成了，因为它的进程已被 date 程序替换。

请注意，exec 仅重定向了 stdout，因此最后的错误消息仍然会显示在屏幕上。 想要将 stdout 和 stderr 都重定向到文件吗？ 这实际上只是一个字符的改变！ 使用以下内容代替上面的 exec 重定向

exec &> output.txt

这很容易，不是吗？

现在，如果用户已将 stdout 重定向到一个文件，但您仍然希望它无论如何都显示在屏幕上，情况又如何呢？ 这是通过 exec 调用中的另一个序列完成的：1>&2，它将 stdout 重定向到 stderr。

让我们看一下与上面相同的脚本，使用 exec 1>&2。 这是发生的事情

$ sh test2.sh > /dev/null
and this goes to stderr
This is still stdout but goes elsewhere
but where does this go?
Sun Oct  7 10:47:44 MDT 2012

非常酷，对吧？

这个月就到这里。 与往常一样，如果您有任何有趣的脚本项目、挑战或想法，请通过 https://linuxjournal.cn/contact 给 我留言，我会看一看。 始终欢迎您的输入！

此外，如果您有非凡的记忆力，您可能会记得 Mitch Frazier 在 2010 年期间在Linux Journal的 Upfront 部分撰写了关于类似主题的文章，但他的方法比我的方法复杂得多。 对不起，Mitch！