So, in bash, I could solve this problem by finding the curl executable. If it doesn’t exist, well, then I add an alias, all as part of my .bashrc. Surely PowerShell has some sort of startup script which could do something similar?
Of course, this might still be backwards incompatible, since the builtin might have different output, in the basic case. But, if PowerShell’s builtin is similar to curl -s, aliasing a found curl executable to curl -s seems like a great compromise.
According to the comments on the PR, you add these to your profile:
I assumed there was a way to remove the aliases. But, by default they are there, which is potentially confusing to users – Daniel’s point. It just seems like the default profile should do the right thing if those binaries are found. But, I reserve the right to be wrong here. :)
I may not have made it clear but I completely agree. The aliases have also existed since the beginning of PS, apparently, breaking curl (and who knows what else) on Windows itself. This is not just about breaking *nix tooling, it’s about overriding behavior of 3rd party programs across a huge deployment whose updates happen irregularly (by OSS standards.)
If nothing else, this is a fascinating case study in how historically insular companies and communities address concerns when moving to open source.
Other programs are also overridden with possibly breaking behavior. cpp is aliased to Copy-ItemProperty, for example.
The PR in question: https://github.com/PowerShell/PowerShell/pull/1901
warning: a LOT of trite and unnecessarily combative responses in there