我阅读了很多init.d脚本，并且：
pid=`cat $pidfile`
read pid <$pidfile
上一个示例使用符合POSIX标准的语法，并且不执行fork / exec来运行外部进程（cat）。
上一个解决方案还允许在第一个换行符后跳过内容。
是否有read命令的陷阱（尽管它执行拆分为字段）？
更新即可。有些人使用非便携式扩展来实现shell：
How to get variable from text file into Bash variable
pid=$(<$pidfile)
答案 0 :(得分：8)
read pid < file方式是最佳实践，因为您说明的原因：比cat的分叉/执行官便宜得多。
至于为什么如此多的脚本以昂贵的方式执行此操作，我只能推测。可能会从其他人的脚本中删除'n'，同时缺乏对shell功能的了解，以及超快的CPU。谁有堆栈溢出时谁会读取手册页？ :-)特别是由于引入了所有术语，shell手册页是一本难以阅读的新手参考手册。
谁说无用的猫是管道的特权？
答案 1 :(得分：2)
查看计算机编程语言可以深入了解为什么通过cat命令初始化pid可能比使用read命令设置pid更好。
由于这个问题与POSIX shell有关，考虑到这种开发的时间表以及其他语言也可能有所帮助。
以C ++为例。尽管C ++与shell完全不同，但实现可移植性的底层机制（这是POSIX的目标）将高度可移植的语言（如C ++）与POSIX shell等脚本语言放在同一类型中。
请记住，除了语言的语法和执行某种格式所产生的成本之外，为了使语言在可移植性方面获得一定程度的自由，语言必须能够与执行命令的硬件接口。
有了这么多说法，C ++提供了使用read命令从pidfile读取的实际成本的一瞥，而不是简单地使用cat命令的输出逐行设置pid变量。
在C ++中，读取用户输入的众多方法之一是使用std :: cin。为了使该过程发生，语言的编译器必须在运行时读入（例如＆gt;＆gt;）用户输入。相比之下，为了执行输出，编译器仅从（例如＆lt;＆lt;）字符串或函数调用中读取。正如各种C ++文本中所提到的，std :: cin并不是一项廉价的任务。
请记住，shell是命令行interpreter，而不是静态类型编译器。
有了这个线索，人们可以得出结论，基于硬件兼容性问题，通过输出设置pid比通过调用read命令从pidfile读取更好。