> That is asinine. Why would a program be called ‘cat’ if it can’t concatenate multiple files?

Because he only thinks it's the "echo file to terminal" command.

The main use of cat was mentioned in the Programming in the UNIX environment article.

> The fact that cat will also print on the terminal is a special case. Perhaps surprisingly, in practice it turns out that the special case is the main use of the program. [...] But what about -v? That prints non-printing characters in a visible representation. Making strange characters visible is a genuinely new function, for which no existing program is suitable. [...] The answer is ‘‘No.’’ Such a modification confuses what cat ’s job is concatenating files with what it happens to do in a common special case - showing a file on the terminal.

http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

Like a lot of people, he overuses cat when it's not needed. `cat FOO | more` is approximately equivalent to `more < FOO`, except the first one spawns an extra process for no reason.

> except the first one spawns an extra process for no reason.

I wonder how many processes I could spin up in the time it would take for me to figure out "hmm, no, invoking that command would use one more process than necessary..."

I don't give a hoot about that stuff when I'm doing stuff interactively. e.g. when using `more`.

In my opinion it's better to replace `cat FOO | more` with `< FOO more`, because cat is used because people first think that they want to take contents of some file and pass it through some filter.

I didn't know you could put the redirection first. You learn something new every day. Maybe that form would make it more mnemonic for some people, because it more resembles a pipeline.

BTW, the authors effectively embraced having the functionality of using `cat` instead of < .

> The use of cat to feed a single input file to a program has to some degree superseded the shell’s < operator, which illustrates that general-purpose constructs - like cat and pipes - are often more natural than convenient special-purpose ones.

If you're going to write shell scripts or do anything sophisticated with the shell, it's worth understanding the difference. And there is a fundamental difference. With |, standard input is hooked up to a pipe. With <, standard input is hooked up directly to the file. Sometimes it does matter.

The purpose cat serves is that it lets you forget about < until you really need it.

The comparison was between cat + pipe and < ...

I like how busybox cat does it, with a do while loop:

https://git.busybox.net/busybox/tree/coreutils/cat.c

"cat" sounds like the abbreviation of "catenate" not "concatenate". Perhaps its possible that later versions of cat allowed more than one argument?

Catenate means to connect things together[1], which implies it was named with multiple files in mind.

[1] https://en.m.wiktionary.org/wiki/catenate

I'd think that it's chaining together the characters in the file, catenating a file to the screen. Wikipedia claims that the first version of Unix did a single file.

https://en.wikipedia.org/wiki/Cat_(Unix)#History

Whereas "con"catenate means to link separate things together. These are minor distinctions, but if somebody is going to call things "asinine" they should at least get the pedantry correct.

The reference Wikipedia gives for that does not actually say that the original “cat” only took one file name. What is says is that “cat”s predecessor, “pr”, only took one file name, and that “cat” subsumed it.

How’s that for pedantry?

Excellent!

Good to know. Reading definitions of concatenate and catenate, I was confused about whether there actually was a difference or not.

Edit: that wikipedia page makes it sound like the program it replaced was the one that prints a single file to the screen.

cat takes as many files as you pass it, yes.