linuxmemes

:(){:|:};:

What the fork does this even do?

I like to alias this to |

Cat outputs your files text and grep searches though that output for occurrences of whatever you feed it. This thing of passing one commands output to another is called piping.

The fuck is a glorp YouTuber?

Which is also exactly what said youtuber said in the same video (assuming this is about who I think it is!).

They also made such reasonable statements as "I also pipe cat into grep when on the command line and playing around with my pipelines, but when it comes to writing full bash scripts to do useful work, think about using grep directly." (not an exact quote btw!)

I prefer less until I find myself using less over and over again until I finally use cat so that I can just scroll up and review whatever I'm looking for.

Is it the best or right way to do things? Nope, but it gets the job done just as good as anything else I do.

And, it goes without saying, I do a terrible job of all of it.

what about $EDITOR <(cat file)?

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?

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.

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