cat file.txt | grep foo is unnecessary and a bit less efficient, because you can do grep foo file.txt instead. More generally, using cat into a pipe is less efficient than redirecting the file into stdin with <, like grep foo < file.txt.
The video I saw was saying cat into grep is totally fine in day to day life do whatever comes out of your fingertips naturally, but if you’re making a bash script for others to use, use grep args because cat pipe grep can do some strange stuff with error handling. Which I have no experience with, but sounds reasonable
It’s less relatable now, and the technology was fucking stupid to begin with, but: Imagine printing out a document and feeding the sheets into a fax machine instead of just sending the file directly to the machine.
Or using a cassette tape adapter to play music from your phone through a stereo system when that system has a built-in Aux port you could plug directly into (“Useless Use Of Cassette?”).
cat’ing into grep, and a handful of other programs people commonly pipe into from cat, is pointless when grep can be called directly against a file. cat is being run for no reason; a useless use of cat (uuoc). It means fuckall for most people today but I imagine it could’ve been an actual concern when hardware was much more limited and multiple users were connecting to a single system.
Grep can accept input from stdin as with a piped cat, but I it can also just call the file directly.
In 99.999% obviouslymadeupstatisobvious of situations its fine.
The real issue is a piped cat into grep will fork the process. Why open two process threads when one would do the job?
Edit: it was mentioned by but to expand a bit: piping cat into grep can also mask quite a few errors. It masks them because of how the shell handles error reporting on piped processes. IIRC, if the file is missing for example, you won’t necessarily know that because while cat will throw a not-found error, that gets piped into grep who gladly accepts the error (which was piped to stdin) as its input and greps through the error, reporting back that your content wasn’t found in the search material, not that the file was missing.
cat sends its error via stderr so it won’t go into the pipe (or grep). you will see the cat error on your terminal, unless you have redirected stderr to stdout
i think the alternative is to use grep args. but ya know i’m living in the future using nushell’s open command and ripgrep so the argument is just kinda adorable
Ok but what is supposed to be bad about grepping into cat? I don’t get it
Edit: thanks for the replies all, I didn’t know you could add a file as an argument in grep. Makes sense now :)
cat file.txt | grep foois unnecessary and a bit less efficient, because you can dogrep foo file.txtinstead. More generally, using cat into a pipe is less efficient than redirecting the file into stdin with<, likegrep foo < file.txt.The video I saw was saying cat into grep is totally fine in day to day life do whatever comes out of your fingertips naturally, but if you’re making a bash script for others to use, use grep args because cat pipe grep can do some strange stuff with error handling. Which I have no experience with, but sounds reasonable
That does sound reasonable. As I will never write such a script for others, I shall continue to cat into grep.
It’s less relatable now, and the technology was fucking stupid to begin with, but: Imagine printing out a document and feeding the sheets into a fax machine instead of just sending the file directly to the machine.
Or using a cassette tape adapter to play music from your phone through a stereo system when that system has a built-in Aux port you could plug directly into (“Useless Use Of Cassette?”).
cat’ing into grep, and a handful of other programs people commonly pipe into from cat, is pointless when grep can be called directly against a file. cat is being run for no reason; a useless use of cat (uuoc). It means fuckall for most people today but I imagine it could’ve been an actual concern when hardware was much more limited and multiple users were connecting to a single system.
Grep can accept input from stdin as with a piped cat, but I it can also just call the file directly.
In 99.999% obviously made up stat is obvious of situations its fine.
The real issue is a piped cat into grep will fork the process. Why open two process threads when one would do the job?
Edit: it was mentioned by
but to expand a bit: piping cat into grep can also mask quite a few errors. It masks them because of how the shell handles error reporting on piped processes. IIRC, if the file is missing for example, you won’t necessarily know that because while cat will throw a not-found error, that gets piped into grep who gladly accepts the error (which was piped to stdin) as its input and greps through the error, reporting back that your content wasn’t found in the search material, not that the file was missing.
cat sends its error via stderr so it won’t go into the pipe (or grep). you will see the cat error on your terminal, unless you have redirected stderr to stdout
What the fork is this forking shirt?
Soz I read your comment as if it were from the good place.
i think the alternative is to use grep args. but ya know i’m living in the future using
nushell’sopencommand and ripgrep so the argument is just kinda adorable