[CrendKing]

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.

[soraminazuki]

In addition to not being a one-to-one port, Sudo for Windows is a completely unrelated command.

> it does the same function which is to elevate a unprivileged command

That's only one of the use cases of Sudo. Here's a description of Sudo from the official manual [1]:

> sudo, sudoedit — execute a command as another user

Sudo for Windows can't do that. It's mentioned in its FAQ:

> the sudo command on Windows does not support running programs as other users

Sudo for Windows is like a cat command that can't concatenate files or a touch command that doesn't update timestamps.

[1]: https://www.sudo.ws/docs/man/1.8.18/sudo.man/

[2]: https://learn.microsoft.com/en-us/windows/sudo/

[Joker_vD]

> like a cat command that can't concatenate files

Oh, that's a good counter-example to your own point: 99% of people who use cat don't care about this functionality.

[soraminazuki]

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:

https://grep.app/search?q=sudo%20-&regexp=true

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.

So again, this naming conflict is unfortunate.

[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