3 ms·

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.