Live data from Hacker News

PSA about abuse of cat(1) command. Don't abuse cats

abuseofcats.com

51–60 of 62 posts

Re: PSA about abuse of cat(1) command. Don't abuse cats

#51
post #33

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 pipin…

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…

The simpler and better way to write your pipeline is:

"There is never any need for "cat".

When such a pipeline is used repeatedly in a script, the time for executing the redundant process "cat" can easily add up to a noticeable delay.

Re: PSA about abuse of cat(1) command. Don't abuse cats

#52
post #26
post #20

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)

I like piping the output of cat and the mental image of one process feeding another. It's inconsequential, but it brings an epsilon of joy.

You have exactly the same mental image if you start a pipeline in the right way, with a file redirection: "This adds the joy of doing only what is really needed, without extraneous effort.

Moreover, in this way the start of a pipeline becomes symmetrical to its end, which frequently is an output redirection.

Re: PSA about abuse of cat(1) command. Don't abuse cats

#55
post #42

Earlier quoted context omitted.

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.

alias less=‘less -X’

Oh nice. Thanks!

Re: PSA about abuse of cat(1) command. Don't abuse cats

#56

Earlier quoted context omitted.

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…

The simpler and better way to write your pipeline is: " There is never any need for "cat". When such a pipeline is used repeatedly in a script, the time for executing the redundant process "cat" can easily add up to a noticeable delay.

That’s neither simpler, nor better.

> "cat" can easily add up to a noticeable delay.

If you have a slow script, you will have more useful places to optimize than removing calls to cat.

Re: PSA about abuse of cat(1) command. Don't abuse cats

#57
post #19

Don't do this: cat file | wc -l => wc -l 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 => The front-cat abuse is all about the order. The effective solution needs to keep the relative order of arguments.

Or just use cat and spend your brainpower on interesting, useful, and/or worthwhile topics. It boggles my mind that anyone cares about this.

And yet you've visited these comments and cared enough to type out one yourself.

I do agree that the performance cost of using "cat" is negligible, but sometimes it's instructive to learn techniques that improve efficiency. Personally, I write a lot of bash scripts and I tend to avoid using external programs when I can use built-ins e.g. "printf" instead of "echo", though avoiding "echo" is recommended anyway due to its lack of POSIX compliance.

Re: PSA about abuse of cat(1) command. Don't abuse cats

#58

Earlier quoted context omitted.

And also typing cat x to get a quick look at the file, hitting up, then piping that into another command and taking a look, hitting up, piping that result into a third command etc.

I suppose a lot of people use less rather than cat for looking at files though. `alt + .` is much more versatile. You can use it to cycle through and insert the last arguments of previous commands.

Sometimes, I'm wanting to copy text from the terminal, so "cat" is a better option if it's more than one page long or you just want to eyeball a fragment that you're going to type into a command.

Re: PSA about abuse of cat(1) command. Don't abuse cats

#59

Earlier quoted context omitted.

All of this depends on your specific shell and its parser. Fish doesn't let you put redirections at the beginning like that (though I wish it did), while GNU Bash does.

fish is not POSIX-compatible, and not Bourne-compatible, so I don't see how that really matters at all. I used the rc shell from plan9 for quite a while, and I wouldn't expect its syntax rules to match, either!

It's worth noting because the redirections and their syntax are nonetheless otherwise shared. I don't think POSIX compatibility for shells is that important tbf. The heart of a Unix shell has little to do with POSIX syntax.

Re: PSA about abuse of cat(1) command. Don't abuse cats

#60

Earlier quoted context omitted.

fish is not POSIX-compatible, and not Bourne-compatible, so I don't see how that really matters at all. I used the rc shell from plan9 for quite a while, and I wouldn't expect its syntax rules to match, either!

It's worth noting because the redirections and their syntax are nonetheless otherwise shared. I don't think POSIX compatibility for shells is that important tbf. The heart of a Unix shell has little to do with POSIX syntax.

I would say that if you can't use the same redirection syntax as Bourne/Bash, then the syntax rules aren't "shared".

And that is because fish isn't POSIX-compliant. It's like when translating languages, some words are cognate, but some are "false friends" and while they look the same, they don't mean the same thing. So when using redirections in fish, the rules may be similar up to a point, but only up to a point.

Post reply on HN