我读了很多init.d脚本和：
pid=`cat $pidfile`
线让我伤心。我不明白为什么人们不使用：
read pid <$pidfile
末示例使用POSIX兼容的语法，而不做fork/exec运行外部程序（cat）。
上次解决方案还允许在第一个换行符后跳过内容。
是否有与read命令任何陷阱（尽管它进行分裂成田）？
UPDATE。一些peole使用非便携扩展外壳，如：
How to get variable from text file into Bash variable
pid=$(<$pidfile)
的read pid < file方式是你说的原因最佳实践：比cat叉/ EXEC便宜得多。
至于为什么有这么多的脚本做到这一点昂贵的方式，我只能猜测。可能会从别人的脚本中删除''''，连同对shell功能的不了解，以及CPU速度非常快。谁有堆栈溢出时读取手册页？ :-)由于引入了所有术语，特别是shell手册页是一本难以阅读的新手参考手册。
谁说猫无用的使用是管用的特权？
看着计算机编程语言提供了一些洞察为什么由cat命令的方式PID初始化人们更愿意使用读命令来设置PID。
因为这个问题是关于POSIX外壳，考虑到这样的发展与其他语言也可能有助于沿时间线。
以C++为例。虽然C++与shell不同，但实现可移植性（这是POSIX的目标）的底层机制将像C++这样的高度可移植的语言与POSIX shell等脚本语言放在同一类型中。
记住，除了语言的语法和执行某种格式所产生的成本外，为了使语言在可移植性方面达到一定的自由度，语言必须能够与执行命令的硬件接口。
有了这么多的话，C++提供了使用read命令从pidfile读取的实际成本的一瞥，而不是简单地使用cat命令的输出逐行设置pid变量。
在C++中，的许多方式来读取用户输入的一个是使用std :: CIN。为了执行此过程，语言的编译器必须在运行时读入（例如>>）用户输入。相比之下，为了执行输出，编译器仅从（例如< <）读取字符串或函数调用。正如在各种C++文本中提到的，std :: cin并不是一项廉价的任务。
请记住，shell是一个命令行interpreter，不是静态类型的编译器。
有了这个线索，人们可以得出结论，基于硬件兼容性的问题，通过调用read命令来设置输出的pid优于从pidfile读取。