我讀了很多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讀取。