It shouldn't. It's 2017 now, and the speed difference between a "misplaced" cat command is normally negligible. The speed of the terminal user is more important.

Also, it makes it easier to add new commands that are not able to read from file in the existing pipeline.

If you are just doing one line and you write it perfectly, then maybe. For many people cat is simply the start if excessive piping. I like having the filename as far at the beginning as possible so I can Ctrl-W with ease.

Using `cat` is wasteful in scripts but not in command line. It separates filenames, which are often actually glob patterns taking some time to confirm, from the parameters, which also often take some time to look up in the manual. `cat` and a pipe make it easier to edit in the command line.

Once I saw this notation, I immediately fell in love:

    <input.txt  tr -d \\n  >output.txt

<file-that-doesnt-exist.txt less

You get a blank screen, but if you do:

cat file-that-doesnt-exist.txt | less

You get a nice error message:

cat: 'file-that-doesnt-exist.txt': No such file or directory

Works for me:

$ < not_existant_file less bash: not_existant_file: No such file or directory

I just tried this on bash 4.3. Cat remains superfluous in this case.

Just tried it again and you're right it does produce an error, I was sanitizing a real error I just had though. With the real one I had an unescaped space, cat mentioned that it couldn't open "both" files, in just gave me a message about and "ambiguous redirect"

Many people chain ps and grep... pgrep does that

That's not a great example as `pgrep` is a little more nuanced than running `ps [options] | grep [string]`, eg you cannot use many of the same `ps` flags `pgrep` like you can with `ps`.

At least with "in appropriate use of cat" (as some call it) you're literally just swapping the stdin file stream with a disk io file stream so there's no functional difference what-so-ever.

I'm not saying I agree with the GP either though as most of the time complaints about "in appropriate use of cat" are just showboating. Using `cat` "inappropriately" is arguably more readable for less seasoned shell script developer and it's certainly a more logical program flow for a human to parse. ie "open file, grep for contents, do something else, etc". But it's still sometimes worth a reminder that many string processing tools can accept file input directly without the need for piping it via stdin (or the files can be redirected directly from the shell via the less than, `<`, token).

> it's certainly a more logical program flow for a human to parse. ie "open file, grep for contents, do something else, etc".

If you mean adding a 'cat' at the start to provide a clear entry-point for the data, you can actually put the redirect at the beginning:

< example.txt grep cheese | tac > cheesy_lines.txt

Indeed, but as I said, the cat complaint tends to be a practice mostly used by those less experienced in the command line so they are probably unaware of `<` let alone that it's placement.

ps | grep | grep -v grep

amirite?

pgrep often fails me I think mostly for apps the edit their cmdline and it needs to whole word match I think?

You can avoid literal matches like so:

    ps | grep [g]rep

Though it is still a bit terrible.