[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.