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.
My pipeline starts with displaying the file to stdout to make sure it's the correct file, and then building on from there, one new program call at a time. This is not a valid alternative.
This. Sometimes I want to see what I'm looking at and then (using that dump as a reference) follow up with a corresponding filter (| jq .key, or | tail -n 30). Sure, I could use less, but then I context switch on exit; no support from the scrollback buffer.
I've probably lost 10ms * 1E5 of my life from the extra PID. But, probably would lose more in the context switch.
I'm never doing just one thing to a file! I'm grepping and JQing and then piping it to JQ again because I'm kind of dumb (and it's faster to do what I do know how to do than it is to look up the perfect way to do it), then I'm outputting as a TSV and piping that to `column -ts $'\t'`. ^r reveals a decent example:
I was figuring shit out along the way and it'd be pretty annoying to adjust which command gets the filename throughout that process.
You know what? I'll tell you another thing I do that's similar:
SELECT * FROM whatever WHERE true
AND last_modified > 123
AND otherfield NOT NULL
Always bugged me that you say WHERE for the first one and AND thereafter, so if I'm poking around the database trying to create actionable insights for key stakeholders at the speed of business just as I was above with the text file, I like to be able to futz and delete/add clauses as I see fit just as I do pipeline stages.
Yeah, I read TFA, and my eyes were rolling the whole time. Some people really have a bee in their bonnet that "cat" is named that way because it was originally for concatenating files. Nobody fucking cares. It's the standard way for writing a file to standard out, and the general pattern of "cat file.txt | somecommand | othercommand | anothercommand" is so useful because it follows the pipeline pattern so well - read from standard in, write to standard out - that is the cornerstone of Unix shell commands IMO.
"Oh no, it spawns another process!!" Again, nobody cares.
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.