pid=`cat $pidfile`还是读取pid <$pidfile？

Question

我读了很多init.d脚本，并且：

pid=`cat $pidfile`

台词让我很难过。我不明白为什么人们不使用：

read pid <$pidfile

最后一个示例使用符合POSIX的语法，不执行fork/exec来运行外部进程(cat)。

最后一个解决方案还允许在第一个换行符之后跳过内容。

是否有使用read命令的陷阱(尽管它执行分裂为字段)？

更新.有些人对外壳使用不可移植的扩展，例如：

如何将文本文件中的变量转换为Bash变量

pid=$(<$pidfile)

Answer 1

read pid < file方法是最佳实践，原因如下:比cat的分叉/执行器便宜得多。

至于为什么这么多脚本这样做昂贵的方式，我只能推测。可能是从其他人的脚本中剪切“n”粘贴，同时缺乏对shell特性的了解，以及速度惊人的CPU。当存在堆栈溢出时，谁会阅读手册页？:-)尤其是shell手册页是新手难以阅读的参考手册，因为引入了所有的术语。

谁说没有用猫是管道的特权？

Answer 2

通过查看计算机编程语言，可以了解为什么使用cat命令初始化pid可能比使用read命令设置pid更可取。

由于这个问题是关于POSIX shell的，考虑到这种开发的时间表以及其他语言也可能有帮助。

以C++为例。尽管C++与shell不同，但实现可移植性的底层机制(这是POSIX的目标)将像C++这样的可移植语言与脚本语言(如POSIX shell )放在同一类型。

记住，除了语言的语法和执行某种格式所产生的成本外，为了使语言在可移植性方面达到一定程度的自由度，语言必须能够与执行命令的硬件进行接口。

这么多话，C++提供了一个真正的成本使用读命令读取从pidfile，而不是简单地设置pid变量逐行使用cat命令的输出。

在C++中，读取用户输入的许多方法之一是使用std::cin。为了实现这个过程，语言的编译器必须在运行时将用户的输入读入(例如>>)。相比之下，要执行输出，编译器只从字符串或函数调用(例如<<)读取。正如在各种C++文本中所提到的，std::cin不是一个廉价的任务。

请记住，shell是命令行翻译员，而不是静态类型的编译器。

有了这条线索，人们可以得出结论，基于硬件兼容性的问题，通过输出设置pid比通过调用read命令从pidfile读取更好。