PSA about abuse of cat(1) command. Don't abuse cats
scooterbooper
27 points
49 comments
July 18, 2026
Related Discussions
Found 5 related stories in 280.0ms across 14,015 title embeddings via pgvector HNSW
- Doomscroll 14,333 cat pictures aadishv · 19 pts · March 07, 2026 · 40% similar
- Pet projects are getting too big to pet nnehdi · 39 pts · July 03, 2026 · 39% similar
- The short leash AI coding method for beating Fable Riseed · 96 pts · July 02, 2026 · 39% similar
- "cat readme.txt" is not safe if you use iTerm2 arkadiyt · 146 pts · April 17, 2026 · 39% similar
- OnlyCats – TikTok for Cats stagas · 24 pts · May 15, 2026 · 39% similar
Discussion Highlights (15 comments)
petee
> Since 1995, occasional awards for UUOC have been given out, usually by Perl luminary Randal L. Schwartz http://catb.org/jargon/html/U/UUOC.html Admittedly its taken me a long time to remember that the file is the last argument to grep, when so many other commands its the first. I'd guess common abuse is due to being easier to type cat x | than to dig up the man page
Shadowmist
I’m going to keep doing it but wouldn’t mind it if my shell auto replaced it for me.
jmclnx
In this day an age this is still making rounds ? So this is the memory usage of cat on my system: VSZ RSS SZ CMD 3252 1608 813 /bin/cat To me there are far more things to worry about than cat. How about your multi-gig browser for one ? Now for firefox: VSZ RSS SZ CMD 3472212 395968 868053 /usr/lib64/firefox/firefox Maybe people should be looking at that ? I will not even get into modern Linux Desktops :)
antonvs
Presumably written by someone without much interactive shell experience. When you're building a pipeline, putting cat first can often be quite convenient. Essentially, it's more composable: it defines the input to the pipeline without committing to a specific tool. For example, you can up-arrow in the shell and change the part after the pipe without having to skip back past the filename. In fact if you don't start with cat, it's possible you're more of a script kiddie than a software developer.
pyrolistical
I like putting the stdin before the command < file grep abc
internet2000
> Piping a single file through cat spawns an entire process whose only job is to copy bytes to a program that already knew how to read them. Chrome probably spawned two processes when I cmd+clicked this into a new tab. It really doesn't matter.
dminvs
"Don't be a catgrepper" - various HostGator employees, c. 2011
lifthrasiir
Don't do this: cat file | wc -l => wc -l < file cat file | head -n 5 => head -n 5 file cat file | awk '{print $1}' => awk '{print $1}' file cat file | sort => sort file Do this instead: cat file | wc -l => <file wc -l cat file | head -n 5 => <file head -n 5 cat file | awk '{print $1}' => <file awk '{print $1}' cat file | sort => <file sort The front-cat abuse is all about the order. The effective solution needs to keep the relative order of arguments.
sprior
I raised eyebrows recently when I was working with someone and we needed to create a file and instead of starting an editor I did: cat > filename ... Ctrl-D
floren
if this wanton abuse of cat(1) doesn't stop, we're on track to run out of PIDs by 2031! Just because Unix makes it cheap and easy to fork doesn't mean you have to! (who gives even a single shit, my god)
MPSimmons
Unless you're executing these commands in a loop over a large number of items, or the item itself is gargantuan, it's almost always harmless. Personally, when I'm exploring, I build a command line iteratively. Cat the file to see the content, pipe to grep to get the lines I want, sed/awk/cut/etc to finagle from there.
copperx
I'll make a note of it in my AGENTS.md file.
jasongi
The beauty of cat is that streams are the universal interface. Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc. But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm piping it into.
mkl
For interactive use like these examples I think this is terrible advice. cat is very helpful because it fits into pipelines like every other command. For example: Take a look at the start of a file: head file Filter for things: head file | grep ... Reformat, remove unwanted stuff, etc.: head file | grep ... | sed ... Do things or dry run echo based on each line: head file | grep ... | sed ... | while read a; do ...; done It all looks good so we change head to cat to run it on the whole file: cat file | grep ... | sed ... | while read a; do... ; done Yes you can technically change "head file |" to "< file" but why bother? That's changes in two places and navigating between them instead of just <alt-d> cat. Same is true for other workflows. E.g. if you start with one of these supposedly better commands like "wc -l < file" (why isn't that just "wc -l file"?): wc -l < file Oh wait, we don't want every line, just ones matching a pattern. We could change it to wc -l <(grep ... file) or grep -c ... file which are both more work than just adding to an existing cat-based pipeline, where we just replace cat with "grep ...": grep ... file | wc -l If we need to also match another pattern or whatever this pipeline approach is better then too.
fragmede
First off, stop using cat, use something modern. I recommend redpanda, rp, but I'm biased since I'm the author. Anyway, the reason I use useless cat is because when I'm working with large files, it starts with head, not cat, or tail, and then only after I've built the pipeline do I use cat to process the whole file.