4 ms·

It always pains me when I see people use "cat" left and right, even when they don't need it. This makes for good reading: http://porkmail.org/era/unix/award.ht

It always pains me when I see people use "cat" left and right, even when they don't need it. This makes for good reading: http://porkmail.org/era/unix/award.html http://porkmail.org/era/unix/award.html

partycoder 9y ago
Many people chain ps and grep... pgrep does that
- laumars 9y ago
  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).
  - lathiat 9y ago
    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?
    - stevekemp 9y ago
      You can avoid literal matches like so: ps | grep [g]rep Though it is still a bit terrible.
  - MichaelBurge 9y ago
    > 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
    - laumars 9y ago
      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.
xfs 9y ago
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.
noja 9y ago
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.
- AstralStorm 9y ago
  It is slower to type too. Just write the command with the file name already.
  - anc84 9y ago
    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.
- eeZah7Ux 9y ago
  Also, it makes it easier to add new commands that are not able to read from file in the existing pipeline.
lucb1e 9y ago
Once I saw this notation, I immediately fell in love: <input.txt tr -d \\n >output.txt
- flukus 9y ago
  <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
  - Tepix 9y ago
    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.
    - flukus 9y ago
      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"

partycoder 9y ago

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

laumars 9y ago
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).
- lathiat 9y ago
  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?
  - stevekemp 9y ago
    You can avoid literal matches like so: ps | grep [g]rep Though it is still a bit terrible.
- MichaelBurge 9y ago
  > 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
  - laumars 9y ago
    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.

xfs 9y ago

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.

noja 9y ago

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.

AstralStorm 9y ago
It is slower to type too. Just write the command with the file name already.
- anc84 9y ago
  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.
eeZah7Ux 9y ago
Also, it makes it easier to add new commands that are not able to read from file in the existing pipeline.

lucb1e 9y ago

Once I saw this notation, I immediately fell in love: <input.txt tr -d \\n >output.txt

flukus 9y ago
<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
- Tepix 9y ago
  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.
  - flukus 9y ago
    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"