我应该照顾不必要的猫吗？

许多命令行实用程序可以从管道或文件名参数中获取输入。对于长Shell脚本，我发现以a开头的链cat使其更具可读性，尤其是在第一个命令需要多行参数的情况下。

相比

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

和

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

后一种方法效率较低吗？如果是这样，差异是否足以关心脚本是否运行（例如每秒运行一次）？可读性差异不大。

“确定的”答案当然是“无用cat奖”给您带来的。

cat的目的是连接（或“连接”）文件。如果仅是一个文件，则根本不进行任何连接将浪费时间，并且会花费您一个过程。

实例化cat只是为了使您的代码能以不同的方式读取，从而只需要一个进程和一组不需要的输入/输出流。通常，脚本中的实际滞留将是效率低下的循环和实际处理。在大多数现代系统上，增加性能cat并不会降低性能，但是几乎总是存在另一种编写代码的方法。

您注意到，大多数程序都可以接受输入文件的参数。但是，总是有内置的shell <，可以在需要STDIN流的任何地方使用它，这可以通过在已经运行的shell进程中进行工作来为您节省一个进程。

您甚至可以在编写的地方获得创意。通常，在指定任何输出重定向或管道之前，它将放置在命令的末尾，如下所示：

sed s/blah/blaha/ < data | pipe

但这不是必须的。它甚至可以排在第一位。例如，您的示例代码可以这样写：

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

如果您担心脚本的可读性，并且您的代码过于混乱，以至于希望增加一行代码，cat使它更容易理解，那么还有其他方法可以清除您的代码。我经常使用的一种有助于使脚本易于稍后查找的方法是将管道分成逻辑集并将其保存在函数中。这样脚本代码就变得非常自然，并且管线的任何一部分都更易于调试。

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

fix_blahs < data

然后，您可以继续fix_blahs < data | fix_frogs | reorder | format_for_sql。像这样的pipleline确实很容易遵循，并且可以轻松调试各个组件的各自功能。

以下是一些缺点的摘要：

cat $file | cmd

过度

< $file cmd

• 首先，要注意：在上面（出于讨论目的）故意缺少双引号$file。在这种情况下cat，除了zsh; 之外总是一个问题。在重定向的情况下，这仅对于bashor ksh88和，对于某些其他shell（仅在交互时（不在脚本中））是一个问题。
• 最常被提及的缺点是产生了额外的过程。请注意，如果cmd是内置的，那么在某些shell中甚至有2个进程bash。
• 仍然在性能方面，除了cat内置的shell中，还有一条额外的命令正在执行（当然，还要加载和初始化）（以及与其链接的库）。
• 仍然在性能方面，对于大文件，这意味着系统将不得不交替调度cat和cmd进程，并不断填充和清空管道缓冲区。即使cmd做1GB大量read()的系统调用的时间，控制将不得不来回之间cat，并cmd因为管道不能保持在同一时刻数据的几千字节以上。
• 有些cmds（如wc -c）可以在其stdin是常规文件时执行某些优化操作，而cat | cmd由于stdin只是一个管道而无法执行。使用cat和管道，这也意味着它们不能seek()在文件中。对于诸如tac或的命令tail，在性能上有很大的不同，因为这意味着cat它们需要将整个输入存储在内存中。
• 的cat $file，甚至它的更正确的版本cat -- "$file"不会像某些特定文件名正常工作-（或--help什么的开始-，如果你忘记了--）。如果坚持使用cat，cat < "$file" | cmd出于可靠性考虑，他可能应该改为使用。
• 如果$file无法打开进行读取（访问被拒绝，不存在...），< "$file" cmd它将报告一致的错误消息（由外壳程序提供）并且未运行cmd，虽然cat $file | cmd仍将运行，cmd但其stdin看起来像是一个空文件。这也意味着，如果无法打开< file cmd > file2，file2则不会破坏file。

推杆<file上的管线的端部比具有较少可读cat file在开始。自然英语从左到右阅读。

把<file一个流水线的启动也比猫少可读，我会说。单词比符号更具可读性，尤其是符号指向错误的符号。

使用cat保留command | command | command格式。

这里其他答案似乎没有直接解决的一件事是，这样的使用cat并不是“无用的”，即“产生了无关紧要的猫进程”；从“催生只执行不必要的工作的猫进程”的意义上讲，这是没有用的。

对于这两种情况：

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

Shell启动一个sed进程，分别从somefile或stdin读取，然后进行一些处理-读取直到打到换行符，然后用'bar'替换该行的第一个'foo'（如果有），然后打印那条线到标准输出并循环。

如果是：

cat somefile | sed 's/foo/bar/'

外壳会生成cat过程和sed过程，并将cat的stdout连接到sed的stdin。cat进程从文件中读取了几千个字节或几兆字节的块，然后将其写到其stdout中，如上面的第二个示例中所示，sed sommand从那里开始拾取。当sed处理该块时，cat正在读取另一个块并将其写入其stdout中，以便sed在下一个工作。

换句话说，添加cat命令所需要的额外工作不仅是产生额外cat进程的额外工作，而且还是两次读取文件字节而不是一次写入字节的额外工作。现在，实际上，在现代系统上，这并没有太大的不同-它可能会使您的系统执行几微秒的不必要工作。但是，如果它是针对您计划分发的脚本的，那么可能是针对那些已经在功率不足的机器上使用它的人们，那么，几毫秒的时间会累加很多迭代。