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.

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

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.

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?

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