为什么Shell无法自动修复“猫的无用使用”？[关闭]

很多人使用单行代码和包含代码的脚本

cat "$MYFILE" | command1 | command2 > "$OUTPUT"

第cat一种通常称为“猫的无用使用”，因为从技术上讲，它需要启动一个新进程（通常是/usr/bin/cat），如果已经执行了该命令，则可以避免这种情况

< "$MYFILE" command1 | command2 > "$OUTPUT"

因为shell只需启动command1，只需将其stdin指向给定文件即可。

Shell为什么不自动执行此转换？我觉得“猫的无用使用”语法更容易阅读，shell应该有足够的信息来自动摆脱无用的cat。的cat是在POSIX标准定义，因此壳应该允许执行它在内部，而不是在路径使用二进制的。Shell甚至可以只包含一个参数版本的实现，并在路径中回退到二进制。

这两个命令并不等效：请考虑错误处理：

cat <file that doesn't exist> | less 会产生一个空流，该空流将传递给管道程序...这样，您最终将得到一个不显示任何内容的显示。

< <file that doesn't exist> less 将无法打开栏，然后再完全打开。

尝试将前者更改为后者可能会破坏希望运行带有潜在空白输入的程序的任何脚本。

“无用的使用cat”更多的是关于代码的编写方式，而不是执行脚本时实际运行的代码。这是一种设计反模式，一种可以以更有效的方式完成某件事的方式。无法理解如何最好地组合给定工具来创建新工具是失败的。我认为在管道中将几个sed和/或awk命令串在一起有时也可以说是同一反模式的症状。

修复cat脚本中“无用的” 实例是手动修复脚本源代码的主要问题。诸如ShellCheck之类的工具可以通过指出明显的情况来帮助解决此问题：

$ cat script.sh
#!/bin/sh
cat file | cat

$ shellcheck script.sh

In script.sh line 2:
cat file | cat
    ^-- SC2002: Useless cat. Consider 'cmd < file | ..' or 'cmd file | ..' instead.

由于shell脚本的性质，很难让shell自动执行此操作。脚本的执行方式取决于从其父进程继承的环境，并取决于可用外部命令的特定实现。

外壳不一定知道是什么cat。它可能是来自您中任何位置的任何命令，也可能是$PATH函数。

如果它是一个内置命令（可能在某些外壳中），则它将具有重组管道的能力，因为它将知道其内置cat命令的语义。在执行此操作之前，还必须对原始命令之后的管道中的下一个命令进行假设cat。

请注意，将标准输入连接到管道和将其连接到文件时，其读取行为会稍有不同。管道是不可搜索的，因此根据管道中的下一条命令的作用，如果重新布置了管道，它的行为可能会或可能不会有所不同（它会检测输入是否可搜索，并决定是否是可输入的，或者是否决定是否做其他事情并非如此，无论如何它的行为都会有所不同）。

这个问题是相似的（在一个非常一般的意义上）“ 是否有尝试修复语法错误，对自己的任何编译器？ ”（在软件工程StackExchange网站），但这个问题显然是有关语法错误，而不是无用的设计模式。但是，基于意图自动更改代码的想法基本相同。

因为它不是没有用的。

在的情况下cat file | cmd，fd 0（stdin）cmd将是管道，在情况下cmd <file则可能是常规文件，设备等。

管道的语义不同于常规文件，并且其语义不是常规文件的子集：

• 常规文件不能以有意义的方式进行select(2)编辑poll(2)；一个select(2)关于它总是返回“准备就绪”。像epoll(2)Linux上的高级界面将无法使用常规文件。

• 在Linux上有系统调用（splice(2)，vmsplice(2)，tee(2)），其仅在管道上的工作[1]

由于cat已被广泛使用，因此可以将其实现为内置的shell，这样可以避免额外的过程，但是一旦您在该路径上启动，大多数命令都可以完成相同的工作-将shell转换为较慢且笨重的命令perl或python。最好使用易于使用的类似管道的语法编写另一种脚本语言作为延续；-)

[1]如果您不希望为此举一个简单的例子，可以在注释中查看我的“来自stdin的exec二进制文件” git gist并提供一些解释。为了在没有UUoC的情况下在其内部实现，将使其增大2或3倍。cat

因为检测无用的猫真的非常困难。

我写了一个shell脚本

cat | (somecommand <<!
...
/proc/self/fd/3
...
!) 0<&3

如果将shell脚本cat删除，则该脚本将在生产中失败，因为该脚本是通过调用的su -c 'script.sh' someuser。显然是多余的，cat导致标准输入的所有者将脚本的运行方式更改为用户，以便通过/proc工作重新打开它。

tl; dr： Shell不会自动执行此操作，因为成本超过了可能带来的收益。

其他答案也指出了stdin是管道和文件之间的技术区别。请记住，shell可以执行以下操作之一：

1. 实现cat为内置工具，仍保留文件与管道的区别。这样可以节省执行人员的成本，也可以节省叉子的成本。
2. 了解各种用于查看文件/管道是否重要的​​命令，然后对管道进行全面分析，然后根据此采取行动。

接下来，您必须考虑每种方法的成本和收益。好处很简单：

1. 无论哪种情况，都请避免执行（cat）
2. 在第二种情况下，当可以进行重定向替换时，请避免使用fork。
3. 在那里你必须使用管道的情况下，它可能是可能有时避免叉/ vfork的，但往往没有。这是因为等效于猫的代码需要与其余管道同时运行。

因此，您可以节省一点CPU时间和内存，尤其是在可以避免分叉的情况下。当然，只有在实际使用该功能时，您才保存此时间和内存。而且，您实际上只是节省了fork / exec时间。对于较大的文件，时间主要是I / O时间（即，猫从磁盘读取文件）。因此，您必须问：cat在性能确实很重要的shell脚本中，有多少次（无用）使用？可以将其与其他常见的shell内置程序进行比较test-很难想象cat（无用的）test使用频率是重要位置使用频率的十分之一。我没有测算这是一个猜测，这是您在尝试实施之前要执行的操作。（或类似地，要求其他人在功能请求中实施）。

接下来，您问：费用是多少。我想到的两个成本是：（a）shell中的附加代码，这会增加其大小（并因此可能导致内存使用），需要更多的维护工作，是bug的另一个发源地，等等。（b）向后兼容的惊人之处，POSIX cat省略了GNU coreutils等许多功能cat，因此您必须非常小心cat内置将实现的功能。

1. 附加的内置选项可能还不错-在已经存在一堆的情况下再添加一个内置选项。如果您有分析数据显示它会有所帮助，则可以说服您最喜欢的Shell的作者添加它。

2. 至于分析管道，我不认为shell当前会做任何这样的事情（一些人意识到管道的末端并可以避免派生）。本质上，您将在外壳中添加一个（原始）优化器；优化器通常是复杂的代码和许多错误的来源。这些错误可能令人惊讶-Shell脚本中的微小更改可能会避免或触发该错误。

后记：您可以对猫的无用使用进行类似的分析。好处：更易于阅读（尽管如果command1将文件作为参数，可能不会）。成本：额外的fork和exec（如果command1可以将文件作为参数，则可能是更令人困惑的错误消息）。如果您的分析告诉您不要使用cat，请继续。

该cat命令可以接受-作为stdin的标记。（POSIX，“ 如果文件为'-'，则cat实用程序应从序列中该点的标准输入中读取。 ”）这允许对文件或stdin进行简单处理，否则将不允许这样做。

考虑这两个简单的选择，其中shell参数$1是-：

cat "$1" | nl    # Works completely transparently
nl < "$1"        # Fails with 'bash: -: No such file or directory'

另一个cat有用的时间是故意将其用作无操作，只是为了维护shell语法：

file="$1"
reader=cat
[[ $file =~ \.gz$ ]] && reader=zcat
[[ $file =~ \.bz2$ ]] && reader=bzcat
"$reader" "$file"

最后，我相信唯一可以真正正确调出UUOC的时间是何时cat使用与已知为常规文件（即，不是设备或命名管道）的文件名一起使用，并且该命令没有给出任何标志：

cat file.txt

在任何其他情况下，都cat可能需要自身的操作。

cat命令可以执行Shell不一定必须执行的操作（或至少不能轻松执行）。例如，假设您要打印可能不可见的字符，例如制表符，回车符或换行符。*可能*只能通过shell内置命令来执行此操作，但是我想不出有什么办法。GNU版本的cat可以使用一个-A或多个-v -E -T参数来实现（尽管我不知道cat的其他版本）。您还可以使用-n（在非GNU版本可以做到的情况下，再次使用IDK）为每行加上行号作为前缀。

cat的另一个优点是它可以轻松读取多个文件。为此，只需键入即可cat file1 file2 file3。要对shell进行同样的操作，事情会变得棘手，尽管精心设计的循环很可能会达到相同的结果。就是说，当存在这种简单替代方法时，您真的要花时间编写这样的循环吗？我不！

使用cat读取文件可能会比使用shell少用CPU，因为cat是预编译的程序（明显的例外是任何具有内置cat的shell）。当读取一大堆文件时，这可能会变得很明显，但是我从来没有在我的机器上这样做，所以我不确定。

cat命令在强制执行可能不接受标准输入的情况下也很有用。考虑以下：

echo 8 | sleep

数字“ 8”将不会被“睡眠”命令接受，因为它从未真正接受标准输入。因此，睡眠会无视该输入，抱怨缺乏论据，然后退出。但是，如果一种类型：

echo 8 | sleep $(cat)

许多shell会将其扩展为sleep 8，然后睡眠将等待8秒钟，然​​后退出。您还可以使用ssh做类似的事情：

command | ssh 1.2.3.4 'cat >> example-file'

该命令在计算机上带有地址为1.2.3.4的附加example-file以及“命令”输出的任何内容。

而且（可能）只是在刮擦表面。我敢肯定，如果我愿意的话，我可以找到更多关于cat的例子，但是这篇文章足够长了。因此，我将以这样的结论来结束：让shell预测所有这些场景（以及其他几种场景）实际上是不可行的。

请记住，用户可以有一个cat在他$PATH这是不完全POSIX cat（但也许一些变体，它可以登录一些地方）。在这种情况下，您不希望外壳将其删除。

在PATH 可以动态改变，那么cat 是不是你认为它是什么。编写一个shell来实现您梦dream以求的优化将是非常困难的。

另外，在实践中，这cat 是一个非常快速的程序。没有什么实际的理由（美学除外）可以避免这种情况。

另请参阅Yann Regis-Gianas在FOSDEM2018上出色的解析POSIX演讲。它提供了其他一些很好的理由来避免尝试在shell中执行您梦dream以求的事情。

如果性能确实是shell的问题，那么有人会提出一个shell，该shell使用复杂的整个程序编译器优化，静态源代码分析和即时编译技术（这三个领域都有数十年的发展和科学出版物，会议，例如SIGPLAN）。令人遗憾的是，即使作为一个有趣的研究主题，该研究目前也不由研究机构或风险资本家资助，而且我推断这根本不值得付出努力。换句话说，优化外壳可能没有重要的市场。如果您有100万欧元可用于此类研究，那么您会很容易找到有人去做，我相信这会带来有价值的结果。

从实际的角度来看，为了提高其性能，通常会使用任何更好的脚本语言（Python，AWK，Guile等）编写一个小的（几百行）shell脚本。而且（出于许多软件工程方面的原因）编写大型的Shell脚本是不合理的：当您编写超过一百行的Shell脚本时，您确实需要考虑使用一些更合适的语言来重写它（即使出于可读性和维护性的考虑）。 ：作为一种编程语言，shell是一种非常糟糕的语言。但是，有很多大型的生成的 Shell脚本，并且有充分的理由（例如，GNU autoconf生成的configure脚本）。

对于巨大的文本文件，将它们cat作为单个参数传递不是一个好习惯，并且大多数系统管理员都知道（当运行任何Shell脚本要花费一分钟以上的时间时，您就开始考虑对其进行优化）。对于大型千兆字节的文件，cat是从来没有处理它们的好工具。

除了@Kusalananda答案（和@alephzero评论）之外，cat可能是任何东西：

alias cat='gcc -c'
cat "$MYFILE" | command1 | command2 > "$OUTPUT"

要么

echo 'echo 1' > /usr/bin/cat
cat "$MYFILE" | command1 | command2 > "$OUTPUT"

没有理由说cat（单独）或系统上的/ usr / bin / cat实际上是cat串联工具。

猫的两种“无用”用法：

sort file.txt | cat header.txt - footer.txt | less

...这里cat用于混合文件和管道输入。

find . -name '*.info' -type f | sh -c 'xargs cat' | sort

...这里xargs可以接受几乎无限数量的文件名，并可以cat根据需要运行任意多次，同时使其行为都像一个流。因此，这适用于xargs sort不能直接使用的大型文件列表。

除了其他方面，cat-check还会增加额外的性能开销，并混淆使用catIMHO实际上是无用的，因为恕我直言，因为这样的检查可能效率低下，并在合法cat使用方面造成问题。

当命令处理标准流时，它们只需要关心对标准文件描述符的读写。命令可以知道stdin是否可搜索/可搜索，这表示管道或文件。

如果添加到混合检查中，实际上哪个进程提供了该stdin内容，我们将需要在管道的另一端找到该进程并应用适当的优化。如Kyle Jones 在SuperUser帖子中所示，这可以根据外壳本身来完成，也可以根据

(find /proc -type l | xargs ls -l | fgrep 'pipe:[20043922]') 2>/dev/null

如链接文章中所示。这是另外3个命令（因此，额外的fork()s和exec()s）和递归遍历（因此，大量readdir()调用）。

就C和shell源代码而言，shell已经知道子进程，因此不需要递归，但是我们如何知道何时优化以及何时cat实际上无用呢？实际上有cat的有用用法，例如

# adding header and footer to file
( cmd; cat file; cmd ) | cmd
# tr command does not accept files as arguments
cat log1 log2 log3 | tr '[:upper:]' '[:lower:]'

将这样的优化添加到外壳中可能会浪费和不必要的开销。正如Kusalanda的回答中已经提到的那样，UUOC的原因更多是用户自己缺乏对如何最佳组合命令以获得最佳结果的了解。