猫的无用的使用？ [英] Useless use of cat?

问题描述

这可能在许多常见问题中 - 而不是使用：

This is probably in many FAQs - instead of using:

cat file | command

（这称为无用的cat），正确的方式应该是：

(which is called useless use of cat), correct way supposed to be:

command < file

在第二个，正确的方式 - 操作系统不必产生额外的过程。 >
尽管知道，我继续使用无用的猫有两个原因。第一 - 更美观 - 我喜欢数据只从左到右均匀移动。并且更容易用别的东西替换cat（gzcat，echo，...），添加第二个文件或插入新的过滤器（pv，mbuffer，grep ...）。

In the 2nd, "correct" way - OS does not have to spawn extra process.
Despite knowing that, I continued to use useless cat for 2 reasons. 1st - more aesthetic - I like when data moves uniformly only from left to right. And it easier to replace cat with something else (gzcat, echo, ...), add a 2nd file or insert new filter (pv, mbuffer, grep ...).

第二个原因 - 我感觉，在某些情况下可能更快。更快，因为有2个进程，第一（猫）做阅读，第二做任何。

2nd reason - I "felt" that it might be faster in some cases. Faster because there are 2 processes, 1st (cat) does the reading and second does whatever. And they can run in parallel, which means sometimes faster execution.

我的逻辑是否正确（第二个原因）

Is my logic correct (for 2nd reason)?

推荐答案

我不知道这个奖，直到今天，一些菜鸟试图固定 UUOC 我的答案之一。这是一个 cat file.txt | grep foo |切割... | cut ... 。我给了他一块我的心，只有这样做后，访问了他给我的链接，指的是奖项的起源和这样做的做法。进一步的搜索引导我这个问题。有些不幸的是，尽管有意识的考虑，没有一个答案包括我的理由。

I was not aware of the award until today when some rookie tried to pin the UUOC on me for one of my answers. It was a cat file.txt | grep foo | cut ... | cut .... I gave him a piece of my mind, and only after doing so visited the link he gave me referring to the origins of the award and the practice of doing so. Further searching led me to this question. Somewhat unfortunately despite conscious consideration none of the answers included my rationale.

我没有防御性的回应他。毕竟，在我年轻的时候，我会写的命令为 grep foo file.txt |切割... | cut ... ，因为每当你执行频繁的单个 grep 时，你会学习文件参数的位置，并且它知道第一个

I did not meant to be defensive in responding to him. After all, in my younger years I would have written the command as grep foo file.txt | cut ... | cut ... because whenever you do the frequent single greps you learn the placement of the file argument and it is ready knowledge that the first is the pattern and the later ones are file names.

这是一个有意识的选择，使用 cat 问题，部分是因为良好的口味的原因（在Linus Torvalds的话），但主要是一个令人信服的功能原因。

It was a conscious choice to use cat when I answered the question, partly because of a reason of "good taste" (in the words of Linus Torvalds) but chiefly for a compelling reason of function.

后者的原因更重要所以我会先把它。当我提供一个管道作为解决方案，我期望它是可重用的。很可能在末端添加管道或者将其连接到另一个管道中。在这种情况下，有一个grep的文件参数提高了可重用性，并且如果文件参数存在，则可以静默地 而没有错误消息。 e。 grep foo xyz | grep bar xyz | wc 会给你在 xyz 中包含 bar 包含 foo 和 bar 的行。在使用之前，必须在流水线中将参数更改为命令，容易出错。

The latter reason is more important so I will put it out first. When I offer a pipeline as a solution I expect it to be reusable. It is quite likely that a pipeline would be added at the end of or spliced into another pipeline. In that case having a file argument to grep screws up reusability, and quite possibly do so silently without an error message if the file argument exists. I. e. grep foo xyz | grep bar xyz | wc will give you how many lines in xyz contain bar while you are expecting the number of lines that contain both foo and bar. Having to change arguments to a command in a pipeline before using it is prone to errors. Add to it the possibility of silent failures and it becomes a particularly insidious practice.

前一个原因并不重要，因为很多好味道只是一个直观的潜意识的理由，例如上面的那些沉默的失败，当你需要接受教育的人说但那只猫不是无用的时，你就无法想象是正确的。

The former reason is not unimportant either since a lot of "good taste" merely is an intuitive subconscious rationale for things like the silent failures above that you cannot think of right at the moment when some person in need of education says "but isn't that cat useless".

但是，我也会努力使自己意识到前面提到的好口味的原因。这是因为Unix的正交设计精神。 grep 不会切和 ls 不会 grep 。因此，至少 grep foo file1 file2 file3 违背了设计精神。正确的做法是 cat file1 file2 file3 | grep foo 。现在， grep foo file1 只是 grep foo file1 file2 file3 的特殊情况，如果不处理

However, I will try to also make conscious the former "good taste" reason I mentioned. That reason has to do with the orthogonal design spirit of Unix. grep does not cut and ls does not grep. Therefore at the very least grep foo file1 file2 file3 goes against the design spirit. The orthogonal way of doing it is cat file1 file2 file3 | grep foo. Now, grep foo file1 is merely a special case of grep foo file1 file2 file3, and if you do not treat it the same you are at least using up brain clock cycles trying to avoid the useless cat award.

这导致我们的论点， grep foo file1 file2 file3 是连接， cat 连接，因此适合于 cat file1 file2 file3 但因为 cat 不连接在 cat file1 | grep foo 因此，我们违反了 cat 和全能Unix的精神。好吧，如果是这样的情况，那么Unix将需要一个不同的命令来读取一个文件的输出，并将其吐出到stdout（不分页它，或任何只是一个纯吐温到stdout）。所以你会有这样的情况，你说 cat file1 file2 或你说 dog file1 并认真地记住避免 cat file1 以避免获得奖励，同时也避免 dog file1 file2 ，因为希望设计 dog

That leads us to the argument that grep foo file1 file2 file3 is concatenating, and cat concatenates so it is proper to cat file1 file2 file3 but because cat is not concatenating in cat file1 | grep foo therefore we are violating the spirit of both the cat and the almighty Unix. Well, if that were the case then Unix would need a different command to read the output of one file and spit it to stdout (not paginate it or anything just a pure spit to stdout). So you would have the situation where you say cat file1 file2 or you say dog file1 and conscientiously remember to avoid cat file1 to avoid getting the award, while also avoiding dog file1 file2 since hopefully the design of dog would throw an error if multiple files are specified.

希望在这一点上，你同情Unix设计者不要包含一个单独的命令来吐槽一个文件到stdout，同时也命名 cat 为连接，而不是给它一些其他名称。 < edit> 删除了< c>< 是一种高效的无复制功能，可以将文件分流到stdout，您可以将其放置在流水线的开头，因此unix设计者确实包含了 < / edit>

Hopefully at this point you sympathize with the Unix designers for not including a separate command to spit a file to stdout, while also naming cat for concatenate rather than giving it some other name. <edit> removed incorrect comments on <, in fact < is an efficient no-copy facility to spit a file to stdout which you can position at the beginning of a pipeline so the unix designers did include something specifically for this </edit>

下一个问题是，为什么有命令只是吐一个文件或者几个文件连接到stdout，没有任何进一步的处理？一个原因是避免每个单独的Unix命令对标准输入进行操作，以了解如何解析至少一个命令行文件参数，并将其用作输入（如果存在）。第二个原因是为了避免用户必须记住：（a）文件名参数的位置;

The next question is why is it important to have commands that merely spit a file or the concatenation of several files to stdout, without any further processing? One reason is to avoid having every single Unix command that operates on standard input to know how to parse at least one command line file argument and use it as input if it exists. The second reason is to avoid users having to remember: (a) where the filename arguments go; and (b) avoid the silent pipeline bug as mentioned above.

这就是为什么 grep 确实有额外逻辑。基本原理是允许用户流畅地使用经常使用的命令，并且基于独立（而不是管道）。这是对正交性的轻微妥协，以显着提高可用性。不是所有的命令都应该这样设计，并且不经常使用的命令应该完全避免文件参数的额外逻辑（记住额外的逻辑导致不必要的脆弱性（错误的可能性））。异常是允许文件参数，如 grep 的情况。 （注意， ls 有一个完全不同的理由，不只是接受，但几乎需要文件参数）

That brings us to why grep does have the extra logic. The rationale is to allow user-fluency for commands that are used frequently and on a stand-alone basis (rather than as a pipeline). It is a slight compromise of orthogonality for a significant gain in usability. Not all commands should be designed this way and commands that are not frequently used should completely avoid the extra logic of file arguments (remember extra logic leads to unnecessary fragility (the possibility of a bug)). The exception is to allow file arguments like in the case of grep. (by the way note that ls has a completely different reason to not just accept but pretty much require file arguments)

最后，可以做的更好的是如果 grep （但不一定 ls ）生成一个错误，如果标准输入在指定文件参数时也可用。这是合理的，因为为了用户方便，命令包括违反Unix的正交精神的逻辑。为了进一步方便用户， e。为了防止由静默失败导致的痛苦，这样的命令应当通过具有额外的逻辑来警告用户如果存在静默错误的可能性，则应当毫不犹豫地违反他们自己的违反。

Finally, what could have been done better is if such exceptional commands as grep (but not necessarily ls) generate an error if the standard input is also available when file arguments are specified. This is reasonable because the commands include logic that violates the orthogonal spirit of Unix for user convenience. For further user convenience, i. e. for preventing the suffering caused by a silent failure, such commands should not hesitate to violate their own violation by having extra logic to alert the user if there is a possibility of a silent bug.

这篇关于猫的无用的使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！