Hi @bagder, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Your change would only affect Windows PowerShell (the version of PowerShell that ships in Windows). Those aliases have existed for multiple releases, so removing them would be a breaking change.

We are rejecting this PR as it introduces "Unacceptable Changes", see our breaking change contract.

If you disagree with this resolution, you will need to start an RFC

Note that our RFC process currently states only team members may create a new RFC. Our intent is to open this up to the community at large, we'll be updating that repo very soon to clarify.

Your change would only affect Windows PowerShell

Well of course, because that's where they were added!

removing them would be a breaking change

You adding them was "a breaking change" to people who were used to using curl and wget from their command lines. No sane person would use those alises anyway since your replacements for curl and wget aren't working anywhere near like the original curl and wget command line tools. These aliases are only making the life harder of the users who actually want the real tools and they don't do anything good for those who don't care for the real tools.

We're not saying here that this isn't a change we can investigate, but per our governance model we need to have a conversation around it. The impact of this change would be far-reaching, and it's not one we can make lightly.

@bagder You bring up a great point. We added a number of aliases for Unix commands but if someone has installed those commands on WIndows, those aliases screw them up.

We need to fix this.

The only Q is what is the best way to do so? As Joey points out - having shipped these, removing them is a breaking change.

We had a vigorous internal discussion about aliases on Linux and had a couple of proposals but decided to start a discussion with the community about what the right solution is (both on Windows and on Linux).

THIS IS NOT A FIX - but if you want to get rid of them for now, you can just add the following to your profile:
Remove-Item Alias:Curl
Remove-Item Alias:WGet

@joeyaiello
Do we already have an RFC for aliases in the queue?
If not - can we start one?

Given that (as far as I can see) your curl and wget "aliases" basically don't implement any of the curl or wget options, I'd disagree with your claim that they are "aliases for Unix commands".

@gevaerts Are you confused about what I was saying or are you suggesting that there is a more precise/constructive way of saying it?

@jpsnover no, I'm not confused. I'm saying it's dishonest to claim that powershell has aliases for "curl" and "wget", as the things that happen when one types a curl or wget in no way resemble what actual curl or wget would do.

You can fix that in two ways: (a) implement both curl and wget functionality completely, or (b) remove those aliases that should never have existed in the first place and make you look bad.

fine.

Nobody is claiming the aliases replace the curl/wget. It may have been misguided to add those aliases in the first place, but the design decision was consistent with other Unix commands, e.g. the Windows PowerShell aliases ps or ls certainly don't work like the native tools.

That doesn't change the fact that we need to weigh the pros and cons of removing them. We also look bad when we break people's scripts that work as they expect today. That's why we have an RFC process to do the right thing for all of our users.

After going through an RFC - we may learn that removing all of our Unix aliases is the right thing to do. Or maybe just removing curl and wget.

It's also possible we end up with getting the best of both worlds - we find a way to invoke the native commands if they exist, but fall back to the aliases otherwise. This certainly has it's own set of problems. For example, if the native command exists, but the script really did want the alias, can we detect that?

The bottom line here is that we really want to do the right thing for all of our customers, starting with where we are today.

Since right now users can have Bash running on Windows, I'd suppose that the all the UNIX utilities should run native on Windows even when running though Windows PowerShell. Having aliases to incompatible commands make users wonder why things break, and if users use the command ls on Windows instead of dir, for example, I guess they would like to use the same command flags they got used to on their Linux and UNIX (as well as MacOS) machines.

It is important to take into consideration that neither 'curl' or 'wget' are "UNIX utilities", and it's deceiving to call them UNIX utilities. I don't know who decided that they were to be considered UNIX utilities, but both curl and wget have been available for native Windows users since at the very latest 2011. Both work natively on Windows without things like cygwin or the new GNU/Linux emulator.

I will go so far as to say that there is no point in worrying about this being a "breaking change" because nobody uses "curl" or "wget" to mean Invoke-WebRequest, which doesn't support any of the command line options of either utility. If anything, the current implementation break scripts, removing these "aliases" would not break anything, but more likely than not would fix scripts.

By current "governance", this would fall under "Changes that don't require an RFC"

@JohnMHarrisJr your assertion that nobody uses the curl or wget aliases to the PowerShell commands has quite a few counterpoints some of which can be seen at https://github.com/search?l=&q=curl++language%3APowerShell&ref=advsearch&type=Code&utf8=%E2%9C%93

@joshka I think you might want to look at those results… They prove my point?

@JohnMHarrisJr

nobody uses "curl" or "wget" to mean Invoke-WebRequest
It is important to be precise.
I suspect that you are correct.
I know that I don't know that.
We just don't have telemetry that tells us that.
PowerShell is installed on many many hundreds of millions of machines and potentially over a billion so I can almost guarantee you that "nobody uses ..." is an incorrect assertion.

Continuing to be precise - we should do something here. We just need to think it through.

Here is a query that illustrates @joshka point:
https://github.com/search?utf8=%E2%9C%93&q=curl++language%3APowerShell+Invoke-JsonRequest&type=Code&ref=searchresults

@jpsnover Yes, I saw that on the first page as I went through the first six pages. That's one in six pages that's using it in a way that it works with the current "alias", and even so it would work without the alias, so my case still stands.

@JohnMHarrisJr
Yup. We hear you.
As I said - we'll open up a RFC on this.
Thanks for the feedback!

@JohnMHarrisJr The example that @jpsnover references would not work with curl.exe - the object assigned would be a string, so this line would fail because System.String does not have a Content property.

@lzybkr Does setting a variable to the output of a program not make it a System.String?

Edit: Actually, I don't see a Content property in either System.String or the undocumented response of Invoke-WebRequest?

Edit 2: Actually, I do see a Content property, I just had to look on a different website to find the actual type 'HtmlWebResponseObject' since it's not on TechNet like Invoke-WebRequest.

@JohnMHarrisJr

The output of Invoke-WebRequest is a Microsoft.PowerShell.Commands.HtmlWebResponseObject.

The output of curl.exe (and every other exe or other command external to PowerShell) is System.String.

So changing curl to run curl.exe instead ofInvoke-WebRequest` would break this script because the output type would change.

@lzybkr Yes, I got that. This is still one script out of six pages at least of results, and the majority of scripts using curl in PowerShell, that show up in the results, are either working around this "alias" or are mistakenly using the "alias".

While I agree with Daniel is a compromise maybe allow it both ways to preserve backwards compatibility? Have powershell detect at runtime what the user intends based on the option casing, for example curl -UpperCamelCase asdf is Invoke-WebRequest

There's no sense in that, and that doesn't solve even the example case we found earlier.

Thanks, I see that example and basically the idea I'm proposing is have some way in PowerShell to auto-detect for backwards compatibility when someone is using curl in a way that it is apparent they mean Invoke-WebRequest. Is it not detectable in that script that they want Invoke-WebRequest? And if there's no sense in that, ok, I don't use PowerShell much so I don't know.

In the context of the curl command, there is no way to detect that they want Invoke-WebRequest, but when a user users curl or wget, they want curl or wget.

@jpsnover I don't like the object-oriented approach when it comes to shells, and bash is the de facto standard on GNU/Linux, so I don't see a reason to switch to another shell. I am also against builtins, in bash terminology, cmdlets in PowerShell. There seem to be a lot of cmdlets in PowerShell by default. One of the major issues I have is that PowerShell doesn't support Readline, so many common key combinations will not work, not that I have tested to see that they were not implemented in another way, such as C-w killing the previous word, C-a taking you to the start of a line and C-k cutting the line past the cursor. Personal projects and personal use aside, the majority of the systems I manage are running FreeBSD. Has there been any effort to test PowerShell on FreeBSD?

@JohnMHarrisJr - PSReadline implements Windows, Emacs, and Vi mode key bindings, and defaults to Emacs bindings on Linux. You'll find it very familiar if you're coming from GNU readline.

@JohnMHarrisJr I hate to be that guy, but you really are missing out. Prior to migrating to a Windows environment, I was scripting in ksh and bash on SCO, AIX, and various flavors of Linux. It seemed really great, and I was definitely a person that thought Windows was awful, simply because of its lack of a functional shell.

But then @jpsnover came along and really did the best thing that has happened to Windows in its entire history, and created (hands down) the most powerful shell to date on any OS. PSv1 was a little clunky, and left a lot to be desired, but once v2 came out, PS became the best scripting language/shell that there has ever been. And really it has only become better with each iteration.

Now, I totally agree if you want to tell me that there should be some plugin that allows vi style editing at the commandline, as that was definitely pretty awesome - but honestly I don't even really miss that anymore, as it is no longer muscle-memory. But being able to pass objects through a pipeline at the command prompt, or in a script is absolutely amazing. I administer over 700 VMs, and I can do the same actions on all of them in minutes. I don't have to write a complex LDAP query, or regex expression to find all those computers - I just filter them based on properties of the ADComputer object sitting right there in the pipeline. Neat! I have thousands of databases across 100s of SQL Servers, and again, in minutes I can query all of those databases for statistics or etc., filtering again on properties of the databases themselves. I can tell you the growth settings, sizes, number of users connected - in just a few lines of code. I can do this across the enterprise with less key strokes than I could on one single server using T-SQL alone. I can manage my entire VMWare environment right from Powershell. AWS - all from Powershell. Pretty near any vendor I have has a Powershell module of some form - and if it doesn't, it has an API - which I can either use directly in Powershell, or write a Powershell module for. It's extensible, it's powerful, it's portable.

Today, I have about 65,000 lines of powershell code across 650 scripts. And because it does have a lot of built-ins, I don't typically have to worry about the state of the machines I run it on. For the most part, they have Powershell so they will run. Now, there may be some modules like SQL server, or Active Directory that aren't always available - and for those I can create a constrained endpoint on a machine that does have those dependencies, and I can invoke those modules remotely and still get the objects back to the pipeline on my calling machine.

Anyway, off my soap box. The fact of the matter is, it was a mistake to use curl and wget initially as aliases for a command that does not do exactly the same things with exactly the same parameters. @jpsnover has acknowledged that. But the fact is, it happened. And because it happened, there will be at least 1 paying customer out there that has utilized those aliases in a critical script, where the author has not been with the company for 5 years, and nobody knows what the script is, what it does, or where it's running. And if they simply remove the alias, that script will break when that customer updates, and no one will know what to do or how to fix it, all they will know is some critical thing broke. Microsoft isn't Linux. Its admins aren't quite as up on the DevOps movement, and so Windows admins are not purposely breaking things to see how fast they can recover, or identify the issue, etc. A lot of admins have dinosaur applications, dinosaur scripts, and when things break they really break, and the admins are not flexible enough to identify and fix the problem. So, MS has at least some duty to try to prevent breaking that customer, regardless of how other businesses or development teams/collaborations do it. So they will use due diligence, come up with a plan, and it will hopefully be far better than just removing the alias and breaking things.

@omrsafetyo awesome post

@JohnMHarrisJr Fully agree, I do not consider any Linux distro, except maybe Gentoo, to be a usable Unix-like OS. Hence, I see no reason to use a tool which isn't available on FreeBSD as well.

@omrsafetyo - if you want vi mode, then add this to your profile: Set-PSReadlineOption -EditMode vi

@ ShinNoNoir

You're proposing a "fix" that does a blind search&replace, no matter where the string "wget" appears in the file? Any idea what your fix does to a hypothetical script like the one below?

You missed the appended note:

(authors note - I suspect really fixing the scripts may require handling additional details, but this is the core of it. )

Really son, I've been coding since 1976, and I've done huge automated code changes.

If your code requires a confirmation for each change on a call to a function like wget, then you have very sad coding practices.

@ rkeithhill

Very nice. :-)

@jkinz
That note was not there, initially.

Really son, I've been coding since 1976, and I've done huge automated code changes.

Then you ought to have learnt what regular languages are.

If your code requires a confirmation for each change on a call to a function like wget, then you have very sad coding practices.

Tell that to a customer whose code you're breaking with your auto-fix script. Such a script is fine if you're applying it to your own codebase and you know what you're doing (because you have additional knowledge about the code), but don't propose it as a general fix for everyone.

@ ShinNoNoir

but don't propose it as a general fix for everyone.

It is a general fix. And as I said before, thats the core of the idea and that additional details will be needed.

You can stop looking for things to correct now. You don't get any points for pointing out things that had no attempt or intent to address. This is not a discussion about the color of the bikeshed. Note again that this was not offered as a specific solution, but the core of an idea.

Since I've worked on projects that automatically edited and ported millions of lines of code, I have no fear that writing tools or scripts that perform such a change on these scripts can be done pretty easily.

Have an excellent day.

Automated fixing is sometimes possible, but it's not foolproof and not as straightforward as we'd like.

There are cases where the use of curl is completely ambiguous - we could not be 100% certain if curl.exe or Invoke-WebRequest was the intended command.

As pointed out previously, it's also possible to call commands in an obscure or obfuscated manner, e.g.

$cmd = "curl"
& $cmd

Furthermore - PowerShell is frequently called from compiled code - most often C# but occasionally other languages. Again, it's certainly possible to analyze binaries or C# or F# or whatever language, but that just increases the complexity of this approach. And as @jpsnover mentioned earlier - with enough users, we tend to see pretty much everything you can imagine.

I would propose to add something like this

#Requires -NoDefaultAlias

to Powershell. It should work this way: any use of alias not defined within the script itself generates an error.

Using a directive is common in scripts to specify the minimal version and will be beneficial in the general case.

@lzybkr One of the major issues is that many users on Windows don't know that they should be typing '.exe' because it doesn't show 'exe' in Explorer. I have found this to be a major issue with my colleagues as well as with scripts by people on GitHub that we pointed out earlier in this thread.

You made a very bad decision when implementing the aliases. Now it's done. There's no point in discussing how bad did you do or how this was yet another case of MS doing what it wants (and doing it wrong in the process).

The point here is there's no solution that will make both sides happy.

• If you remove the aliases you'll be breaking production scripts out there.
• If you keep the aliases, let's forget about the whole Bash on Windows flares, because it's not really serious.

I think the most sane decision is to remove the aliases and take proper responsibility:

1- review all the aliases (not only wget or curl), understand potential conflicts;
2- deprecate the aliases immediately; print warnings when used;
3- implement something like @giuliov mentioned above;
4- build tooling that people can use to translate their scripts (or make them running in a transient environment where the aliases still exist) in case they want to keep relying on this behavior;
5- send newsletters to all the subscribed developers;
6- make communication on all developer community forums, chats, workspaces;
7- you want to further help the community? build a bot that queries GitHub, Bitbucket and other popular source code repositories in a way similar to what @joshka wrote, and automatically create an issue there telling what's going on;
8- prepare your Support Center to deal with the issues from the paying customers;
9- release the changes X months from now.

@bagder Well, "If the mountain won't come to Muhammad then Muhammad must go to the mountain".
Maybe you can rename curl.

Probably off topic a little bit, but I will just keep stay away from windows as I'm already doing it and be happy :-)

@luisfarzati I don't really have a dog in this fight as I personally find PowerShell to be just short of abhorrent... but your recommendations are the most sensible. I was going to actually recommend your suggestion 2 as well, as it's most sensible. Throw errors when people are doing stupid things. If they're using wget or curl within the wrong context, they should be redirected to the proper command that they're aliases of and told to immediately update their scripts via a descriptive error message.

After thinking it again, #4 on my post above would be really easy and simple to understand. Maybe not quite elegant, but hey... we can't ask for fanciness when we have a wrong implementation of wget. :)

What if you just provide a simple runner that lets you run the script in a way that any call to those aliases keep working as expected?

No changes to your scripts, just call them with a separate command, or maybe not even a command, just an argument modifier like --legacy-aliases or something.

@luisfarzati

No changes to your scripts, just call them with a separate command, or maybe not even a command, just an argument modifier like --legacy-aliases or something.

Which means that if a script is scheduled to run somewhere, and PowerShell has been updated on that machine, it could potentially break because people forgot to add the new command flag?

@ShinNoNoir Yes, that's why my point #2 above is about PS complaining for some reasonable long time, which gives you enough time to review and fix. As with any other service, you don't upgrade PowerShell just because. Specially in production environments. Would you upgrade mysql, redis, Node, nginx, etc without reading implications, changelog, potential drawbacks? Don't think so.

If you are involved in Windows and specifically PowerShell development, there's a good chance you found out about this over the 2, 3, 4?-month span since deprecation notice. #5, #6 and #7 should help you get the news somewhere.

But, if you want to be more conservative, maybe the switch to the "new PowerShell behavior" could be configured at upgrade time. Simple Yes/No dialog which can be reconfigured again later via command line, registry, whatever Windows developers like. PS should then also include a way for a script to determine if it's running in legacy aliases mode or not.

On Wed, Aug 24, 2016 at 3:39 PM, Raynor Vliegendhart <
notifications@github.com> wrote:

@luisfarzati https://github.com/luisfarzati

No changes to your scripts, just call them with a separate command, or
maybe not even a command, just an argument modifier like --legacy-aliases
or something.

Which means that if a script is scheduled to run somewhere, and PowerShell
has been updated on that machine, it could potentially break because people
forgot to add the new command flag?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1901 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGj9S8em4Sq1-i6A3mTBxgTWimRTTsJks5qjI_0gaJpZM4Jn1fs
.

Which means that if a script is scheduled to run somewhere, and PowerShell has been updated on that machine, it could potentially break because people forgot to add the new command flag?

@ShinNoNoir this is exactly why I don't like the idea of the "Remove-All-Aliases-That-Are-Linux-Commands" function that can be inserted into a profile or at the top of scripts - again this would require knowing what scripts are using aliases, and which aren't, and a massive community effort to determine which scripts/profiles need updating before upgrading - essentially the same effort that would be required to simply go through and convert any instances of those aliases to the proper fully-fledged commandlet names.

@omrsafetyo But Nathan, you see, the problem is this:

I use my Linux notebook and use wget and it behaves as expected.
I use my Macbook and use wget and it behaves as expected.
I use my Windows desktop and use wget (which I previously downloaded) and it behaves as expected.
I login to some Amazon EC2 instance and use wget and it behaves as expected.
I configure some Jenkins job and make it use wget and it behaves as expected.

But -- in PowerShell, wget is a completely different beast. You have something that is practically as universal as echo, that responds differently in just one specific case: PowerShell.

That doesn't make any sense. Not just for *nix users, or OSS developers. It shouldn't make sense for anyone, including Windows/PS developers.

There was a time when MS did things like this all the time, remember the web?

In recent years they have shown a change of convictions and a solid commitment to the OSS community. This is one of the challenges they need to face. The right answer, not because I say so, but because they are the ones trying to amend things, is to make wget respond as wget. We all should be asking for this, hopefully after having learned a few painful lessons in the past decade of the web.

Come on, this is not the first time a breaking change is introduced in a tool or a system and won't be the last. Breaking changes, although not frequent, are part of our challenges as developers. Mass-consumed APIs suffer from breaking changes from time to time and it's not the end of the world, specially with proper notice, feedback and community support.

The good thing about being part of the OSS universe, is that you are now part of a community larger than whatever you may have know before. You know what? If you decide to deprecate the aliases and schedule the definitive removal at some point in the future, you'll probably find out you don't even have to do half of the things I enumerated before: the community itself will provide help and guidance, even build the tools. That's how this works! :)

What if millions of Linux systems were deployed with powershell as an alias to bash?

@thedaveking Good idea! Let's deploy a version of Firefox that auto-redirects all microsoft.com links to mozilla.com instead. (Only microsoft.com. URLs will stay without the redirect).

Let's see how fast Microsoft starts suing the shit out of the people responsible. That should be the standard held up here, too.

EDIT: Obvious exaggerated example is obvious, but quick action is necessary before people start hard-coding these workarounds to get wget into their scripts.

This is not helping. Not only the OP asked to "stay polite and to the point when commenting here", but also sadly half of this thread is worthless and doesn't bring any ideas or value to the discussion.

@luisfarzati I don't want to spend much time talking the history of Web but basically the fact is that the web standards were created by Microsoft haters and were dedicatedly incompatible with what had been implemented by Microsoft before the standards came out. Of course Microsoft was not responding fast to the changing Web. So the Web should be a lesson for us, but in a different way/sense.

Not all users of PowerShell are part of community and you can't expect them to respond to such changes. And not to mention no one here suggesting the removal really cares about "the serious commitment to backward compatibility."

The removal is possible, only if you keep these things there for all old scripts. For that, there are many ways, excluding trying to notify everyone before something breaks.

Let's stick to the topic and take the other discussions to a different forum so people that care about the issue don't have to struggle with a low signal-to-noise ratio.

Thanks for all the feedback. I'm locking this thread as we've gotten sufficient feedback and the conversation is bordering on being not useful.

The team has published an RFC and you can discuss the RFC here.