I disagree. Although this "Sudo for Windows" is not a one-to-one port from Linux, it does the same function which is to elevate a unprivileged command. Imagine if they announce "Introducing Dosu for Windows", you won't know what the hell that is without reading at least the first paragraph.
That's an astonishing claim to make without evidence.
cat *.txt
is a pattern I see being used everywhere.
Same goes for sudo. If you're going to claim that a whopping 99% of users don't use the CLI options or /etc/sudoers, you'd need solid proof. Because a simple search shows otherwise:
This Sudo for Windows behaves nothing like the actual sudo. It doesn't even achieve the original's stated purpose.
Also considering that search results for anything involving Windows tends to be riddled with spams and outright scams, this will negatively affect non-Windows users searching for sudo as well.
> "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.
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:
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.
> 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
> "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.
