What was the thought process to add those aliases? "Yes let's implement broken aliases that supersedes actual working windows version of those utilities" ?
I'd guess they started with stuff like "ls" (where it makes a lot more sense to just execute a windows equivalent, at least in interactive use) and then somewhere someone was a bit to enthusiastic?
For stuff like this "weak" aliases which point you to the right command if it can't find an executable for it would have been a way better design. "No command with that name, you are likely looking for Invoke-WebRequest". Only slightly more work in interactive use, and safe in other cases.
Yes, but the dir/ls alias behaves nothing like it's counterparts, so it's actually confusing when you use dir or ls but none of the familiar usage works.
Just wanted to add my two cents here that I normally use `ls` on PowerShell (instead of `dir` or `get-childitem` or `gci`) because it seems expedient. (I come from a Unix background.)
Yes, it does confuse me that plain `ls` in PowerShell is more like `ls -l` on Unix, and this confusion sometimes causes me to type `ll` (my normal Unix alias for `ls -l`). But still, I prefer `ls` over `dir` in PowerShell.
So I guess I'm saying that I'm fine with some of the aliases. (But `curl` and `wget` should be removed, yes.)
Hypothesis: The Windows world is a closed ecosystem. The developers and most of the users aren't familiar with any of the non-Windows systems. They were given a list of commands to map to the closest Powershell equivalent and made aliases for the basic functionality.
That is the only explanation I can see for why the would pick those commands.
Back when it was introduced, PowerShell effectively had a set of commands no one knew. To ease migration, and make things more familiar, aliases were added for many common Unix and cmd commands, e.g. both dir and ls map to Get-ChildItem.
However, having those aliases (not even limited to curl/wget or all the Unix-like aliases like ls, cp, rm, ...) is a risk since they shadow native programs that might exist. It's not as bad with dir, copy, del, since those are cmd-built-ins and thus cannot be called from anything that isn't cmd, but where already shadows where.exe.
So in general, since command resolution order places aliases before native programs, any default alias can break stuff on any machine. Which places this in pretty iffy territory. They cannot remove aliases without breaking existing scripts. This is still Microsoft we're talking about here. They don't just go around breaking stuff left and right. And they actually could never have safely introduced default aliases without a chance of breaking things.
They aren't necessarily built-ins. Years ago, I wrote a CMD where DIR, COPY, DEL, and others were intentionally not built-in. I even supplied it with two different versions of an external COPY command, one with syntax that was aligned with MOVE, REN, and so forth, and one with the full original idiosyncratic syntax of the IBM/Microsoft COPY command (that could concatenate multiple parallel lists of files).
I went in a different direction to JP Software's (then) 4OS2, which took the tack of adding futher built-in commands. JP Software's (current) Take Command is interesting to consider in light of this discussion. It has its own built-in versions of bzip2, gzip, jabber, rexec, rshell, sendmail, tail, tar, zip, 7zip, and others.
To help bridge the gap for UNIX users who are switching over - but that being said, it's dumb since I think having the same commands that don't function the same way as the UNIX tools would confuse me more than not having them at all and having to learn a new web request command.
It's great to make things better for your users. But that doesn't make it ok to use other's IP to do so. For decades MS has used IP to crush it's competition, so there is absolutely every reason to treat this type of behavior from them as hostile. Is MS gonna give back all the $ Google paid it for Android lawsuits? No? Then it's still just business.
Powershell is an object world, cURL is a string utility. You wouldn't want to bundle it, you want people to use Invoke-WebRequest (current cURL alias).
The alis just needs to be removed. They should replace it with a manpage that suggests cmdlets for popular UNIX commands if those commands aren't found (e.g. if curl returns "not found" it tacks on, "You could try XYZ cmdlet instead").
Powershell is an object world, cURL is a string utility. You wouldn't want to bundle it, you want people to use Invoke-WebRequest (current cURL alias).
Specifically, for non PS users reading, Invoke-WebRequest returns n object with the page content parsed and a live DOM to work with, as well as the request headers and the raw data. It's very convenient.
If they really wanted to help users switching from Linux/Unix etc. then invoking commands like 'ls' would display a help page informing users how to get the functionality from native tools.
wget and curl aren't included with Windows. You have to go out and get them.
Powershell does come with Windows. If you don't know Powershell, having wget aliased to Invoke-WebRequest is hugely convenient, because it's the quickest way of getting stuff done; assuming your Linux knowledge is somewhat, sorta valid is a lot easier than reading a bunch of documentation or googling to see what the actual name of the command is (even though Powershell has pretty discoverable commands.)
For stuff like this "weak" aliases which point you to the right command if it can't find an executable for it would have been a way better design. "No command with that name, you are likely looking for Invoke-WebRequest". Only slightly more work in interactive use, and safe in other cases.