4 ms·

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

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:%5Egithub%5C.com/git/git%24+%5Cbcat%5C+%28%5Cw%28%5Cw%7C%5B-/*%5D%29*%5C+%28%5Cw%7C%5B-/*%5D%29%2B%28%5B%5E%3C%3E%5D%7C%24%29%7C%5B%5E+%3C%3E%5D*%5C*%29&patternType=regexp&sm=0 https://sourcegraph.com/search?q=context:global+repo:%5Egith...

Joker_vD 3y ago
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 https://grep.app/search?q=cat%20.%2A%3E%3E&regexp=true
- soraminazuki 3y ago
  > 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 3y ago
    > "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.
- deleted 3y ago
  [deleted]
cchance 3y ago
lol i didnt even know cat did that lol!

Joker_vD 3y ago

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 https://grep.app/search?q=cat%20.%2A%3E%3E&regexp=true

soraminazuki 3y ago
> 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 3y ago
  > "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.
deleted 3y ago
[deleted]

cchance 3y ago

lol i didnt even know cat did that lol!