I find this comment most important in all discussion:

>To be honest, I don't see how this dscussion about how many people might depend on these aliases is relevant. The story as I see it is that a few years ago you decided to usurp the names of some well known tools, in the full knowledge that doing so would break those tools. You have then ignored bug reports about this for years. You really can't deny that you knew a long time ago that what you did amounted to hostile behaviour towards other people.

How is that comment useful? No-one is denying anything. It's obvious that the decision to implement those aliases was incorrect. It's not like Microsoft is saying that it was correct.

It's not a question of who was right or who to blame. It's a question of how to make the changes because there _are_ users that depend on those aliases.

They are also honestly pretty useful as a new user. `ls` and `dir` are more obvious things to try than `Get-ChildItem`.

The half-way solution could have been making the 'aliases' output migration documentation about how to accomplish common takes with the PS commands.

That way PS would be far more discoverable to a UNIX person and would save time searching "$command in powershell".

Yeah but frankly it also sucks to type in such a long command rather than using the aliases.

Most of the commands have PS "native" aliases which also follow a more consistent pattern, e.g., get-childitem->gci, invoke-webrequest->iwr.

That's true, but after years of typing "ls" into terminals that's just more natural.

Then maybe design new ones?

"download" aka "dl" instead of curl/wget?

"list" instead of ls/dir?

Would also make them easier googleable

That's not the problem MS was trying to fix with the Linux aliases -- the problem they were trying to fix was ergonomics. A lot of us are used to Linux commands and are turned off by Windows shells when we have to learn a new set of commands and can't use `ls`.

In fact, being able to do `ls` rather than `dir` on PowerShell was one big reason I gave it a chance. My other Windows shell experiences have been supremely intolerable because of that.

With curl and wget, Microsoft admits they were overeager.

I think the correct ergonomics would be if you saw:

  $ curl http://example.com/foo
  Fetching http://example.com/foo by emulating curl
  This command is an alias for "...".
  If you've installed a real curl command, disable this by typing...

so that you could still use muscle memory to type the commands you know, could see what the actual underlying command is so you could adapt to it, and would know how to use the Real Thing if you have it.

Kind of noisy, isn't it?

It is, but the noise is telling you how it differs from what you'd normally expect and how to address it. I think that's an acceptable tradeoff.

I think it is immediately obvious from the output that it's not the same program, without the message.

Really? What's the normal output? The content of the URL being fetched. If that message was to STDERR so that curl > foo worked without alteration but the help text still showed up on the console, I think fewer people would be surprised.

The number of bugs about this indicates that people are still being surprised.

That is not the output of the PoSh command. Like most of them it outputs a list of object properties and values: https://mcpmag.com/articles/2013/01/22/~/media/ECG/mcpmag/Im...

PowerShell has other ones in addition to the cannibalistic ones. `Get-ChildItem` has `gci` and the command in question, `Invoke-WebRequest` has `iwr` on top of `wget` and `curl`. Admittedly, it's pretty kitchen sinky.

So, there’s already a solution.

Those are not discoverable in the same way.

I think this comment is important in understanding why so much open source software doesn't have backwards compatibility

> If removing these aliases (retroactively, if you want to clean up your act you have to remove this from all versions in which this was ever released) breaks things for some people, then you can go and send people out to help them fix their issues. You knew it was a hostile action, you broke things, you fix them.

retroactively remove things from old versions? This is crazy

No one does that. How is this comment from someone who doesn't understand the "release" concept so important?

When I had no customers - I had lots of flexibility.

PowerShell is now installed on many hundreds of millions of machines.

With great success comes great responsibility.

We can and will change things but we have to do so in a thoughtful manner.

Jeffrey Snover [MSFT]

Kind of worrying that the inventor of PowerShell could make such a mistake. Reminds be of when rvm used an alias for "cd", which was even worse. Making up alias for popular tools such as cd, curl or wget is always a bad idea both for security and practical reasons since it breaks many tools in non-obvious ways and can be hijacked etc. It's great though that it's being fixed.

I installed PS on my ubuntu last night, it works but I don't really see the point in using it on anything but windows. Last thing I need is worry whether my scripts will run on my custom shell script as if running ubuntu didn't come with its own issues to worry about already.

> Making up alias for popular tools such as cd

cd is a shell builtin on every single *nix shell, not an independent tool. Every shell has its own cd implementation.

You might also add that it's actually impossible to implement cd as a standalone tool - processes cannot change their parent's working directory.

It's not pretty, but you can: https://rudd-o.com/linux-and-free-software/the-shell-challen...

Well how about that. Serve me right calling something "impossible".

Now what do I say? "Impossible without awful hackery"?

Are other commands also different from shell to shell? It seems like an interesting point, if true.

Lots of simple shell functionality is provided as builtins. See the bash manual for a list of builtins inherited from the Bourne Shell[1] and that are bash-specific[2].

Note that some of these are part of the POSIX standard, so there's not a huge amount of variance allowed between shells which are being compliant. Obviously, PowerShell doesn't adhere to this.

[1] https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh...

[2]: https://www.gnu.org/software/bash/manual/html_node/Bash-Buil...

Here's a couple of pages listing the builtins in bash: https://www.gnu.org/software/bash/manual/html_node/Shell-Bui...

And zsh: http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Command...

Powershell doesn't really have "builtins" per-se, every cmdlet is executed in the process of the shell itself but they're all contained within loadable modules (though 2-3 modules are loaded with the shell startup by default), Invoke-WebRequest is contained within Microsoft.PowerShell.Utility for example.

> The thread goes on at length about bureaucratic requirements for the change.

I don't like the characterization of the RFC process as a bureaucracy. RFC processes are more open than a pure "bazaar". In the lack of any formal, open process to make project changes, there ends up being a hidden informal "be friends with this person to get your patch merged" process, which is far less transparent.