我應該關心不必要的貓嗎？

許多命令行實用程序可以從管道或文件名參數中獲取輸入。對於較長的 shell 腳本，我發現以 a 開頭的鏈cat會使其更具可讀性，尤其是在第一個命令需要多行參數的情況下。

比較

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

和

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

後一種方法效率低嗎？如果是這樣，差異是否足以關心腳本是否執行，例如每秒一次？可讀性差異不大。

“確定的”答案當然是由The Useless Use of catAward帶給你的。

cat 的目的是連接（或“連接”）文件。如果它只是一個文件，那麼將它與任何內容都連接起來是浪費時間，並且會花費您一個過程。

實例化 cat 以使您的程式碼以不同的方式讀取只會增加一個程序和一組不需要的輸入/輸出流。通常，腳本中真正的阻礙將是低效的循環和實際處理。在大多數現代系統上，額外cat的一個不會影響您的性能，但幾乎總是有另一種編寫程式碼的方法。

正如您所注意到的，大多數程序都能夠接受輸入文件的參數。但是，在任何需要 STDIN 流的地方總是<可以使用內置的 shell，這將通過在已經執行的 shell 程序中完成工作來為您節省一個程序。

您甚至可以通過 WHERE 編寫來獲得創意。通常，在您指定任何輸出重定向或管道之前，它會放在命令的末尾，如下所示：

sed s/blah/blaha/ < data | pipe

但不一定是這樣。它甚至可以排在第一位。例如，您的範常式式碼可以這樣編寫：

< data \
   sed s/bla/blaha/ |
   grep blah |
   grep -n babla

如果腳本的可讀性是您關心的問題，並且您的程式碼非常混亂以至於添加一行 forcat可以使其更容易理解，那麼還有其他方法可以清理您的程式碼。我經常使用的一種有助於使腳本稍後更容易理解的方法是將管道分解為邏輯集並將它們保存在函式中。然後腳本程式碼變得非常自然，並且管道的任何一部分都更容易調試。

function fix_blahs () {
   sed s/bla/blaha/ |
   grep blah |
   grep -n babla
}

fix_blahs < data

然後，您可以繼續fix_blahs < data | fix_frogs | reorder | format_for_sql. 像這樣讀取的管道非常容易遵循，並且可以在各自的功能中輕鬆調試各個組件。

引用自：https://unix.stackexchange.com/questions/16279