[Joker_vD]

> "cat *.txt" is a pattern I see being used everywhere.

That's an astonishing claim to make without evidence. I don't see "cat *" being used anywhere. In fact, I've just ran search for usage of "cat" over the repository of shell scripts that are used for the various packaging and deployment tasks in my company (and we have to deploy a lot of stuff, written in different programming languages, and every team packages their stuff into their docker containers in their own way but it's all still documented in this repo) and every single use of cat is either

a) reading data into a variable "VAR=$(cat file_with_data)";

b) writing inline data from script into a file "cat >>$TARGET_FILE <<EOF ... EOF";

c) an entirely reasonable use of cat "cat file | utility_that_accepts_filenames_too", sometimes even "cat file | utility".

None of them take a pattern or more than one file.

UPD: I've ran "cat *\." on the grep.app, and it seems that it's used mostly for bulk log processing; I vaguely recall we moved away from it to using custom reader scripts because the asterisk doesn't expands into the files ordered the way we needed.

[soraminazuki]

The onus isn't on me to disprove that 99% of cat users don't care about concatenation, but here's a non-comprehensive list of projects using cat to concatenate files:

OpenSSL, Curl, Git, Linux, Gettext, NodeJS, zstd, GCC, FFmpeg, OpenJDK, Pyenv

I think users, upstream developers, and downstream packagers of these software will all be upset if cat ceased to concatenate.

Example:

https://sourcegraph.com/search?q=context:global+repo:%5Egith...

[cchance]

lol i didnt even know cat did that lol!

[Joker_vD]

Half of those examples from git don't even invoke cat, another quarter don't concatenate files, and the final quarter use it for preparing test data. Well, I guess the last is a valid use although again, most of those uses could've used printf "$chunk_of_data" >>output instead of writing temporary files all over the temp directory, and I imagine the "git am" test could've been written as "git am patch1 patch2" instead. shrugs I guess it's 80% then.

UPD: And lots of people use "cat file1 >>output; cat file2 >>output" for concatenation anyhow [0]. Apparently shell already can concatenate things well enough, so cat should do one thing and do it we;l: dump a single file contents to stdout /s.

[0] https://grep.app/search?q=cat%20.%2A%3E%3E&regexp=true

[soraminazuki]

> Half of those examples from git don't even invoke cat

That's because it's a regex search and not relevant to the point at all. What matters is that people use widely advertised features of a popular tool, including sudo and cat. Especially if that feature is the single stated purpose of the tool.

Taking a name of a widely used tool and slapping it on something that doesn't even do what the original was made for isn't a nice thing to do. I don't get why that's controversial to anyone.

> so cat should do one thing

That one thing is con-"cat"-enating files, so to speak. Why should it become something different just to make the name Sudo for Windows appear somehow less misleading?

Also,

    rm out.txt
    for f in *.log; do cat "$f" >> out.txt; done

is a clunky way of concatenating files.

    { for f in *.log; do cat "$f"; done; } | less

Even clunkier.

[soraminazuki]

> "git am" test could've been written as "git am patch1 patch2" instead

This is off topic, but the Git devs were correct in doing `cat pine patch1 | git am`, since the test in question is

    test_expect_success 'am takes patches from a Pine mailbox'

The test requires the mailbox not be split in two, so `git am pine patch1` is out of the question. patch1 is reused across multiple tests, so it makes sense for it to be in separate files. Concatenating is the logical conclusion.

    cat patch1 >> pine
    git am pine

is possible, but why? It's more code and it mutates the contents of files after initial creation, making the tests as a whole slightly harder to reason about.