New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initialsession: remove curl and wget aliases #1901

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@bagder

bagder commented Aug 18, 2016

They block use of the commonly used command line tools without providing
even an attempt to offer the same functionality. They serve no purpose
for PowerShell users but cause confusion and problems to existing curl
and wget users.

Update: Stay polite and to the point when commenting here. This pull-request is not an excuse to be rude or off-topic.

initialsession: remove curl and wget aliases
They block use of the commonly used command line tools without providing
even an attempt to offer the same functionality. They serve no purpose
for PowerShell users but cause confusion and problems to existing curl
and wget users.
@msftclas

This comment has been minimized.

msftclas commented Aug 18, 2016

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;

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 18, 2016

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.

@lzybkr lzybkr closed this Aug 18, 2016

@bagder

This comment has been minimized.

bagder commented Aug 18, 2016

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.

@joeyaiello

This comment has been minimized.

Member

joeyaiello commented Aug 18, 2016

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.

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 18, 2016

@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

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 18, 2016

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

@gevaerts

This comment has been minimized.

gevaerts commented Aug 18, 2016

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".

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 18, 2016

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

@gevaerts

This comment has been minimized.

gevaerts commented Aug 18, 2016

@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.

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 18, 2016

fine.

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 18, 2016

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.

@tomer

This comment has been minimized.

tomer commented Aug 18, 2016

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.

@JohnMH

This comment has been minimized.

JohnMH commented Aug 18, 2016

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"

@joshka

This comment has been minimized.

joshka commented Aug 19, 2016

@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

@JohnMH

This comment has been minimized.

JohnMH commented Aug 19, 2016

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

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 19, 2016

@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.

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 19, 2016

@JohnMH

This comment has been minimized.

JohnMH commented Aug 19, 2016

@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.

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 19, 2016

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

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 19, 2016

@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.

@JohnMH

This comment has been minimized.

JohnMH commented Aug 19, 2016

@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.

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 19, 2016

@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.

@JohnMH

This comment has been minimized.

JohnMH commented Aug 19, 2016

@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".

@jay

This comment has been minimized.

jay commented Aug 19, 2016

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

@JohnMH

This comment has been minimized.

JohnMH commented Aug 19, 2016

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

@jay

This comment has been minimized.

jay commented Aug 19, 2016

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.

@JohnMH

This comment has been minimized.

JohnMH commented Aug 19, 2016

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.

@JohnMH

This comment has been minimized.

JohnMH commented Aug 22, 2016

@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?

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 22, 2016

@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.

@omrsafetyo

This comment has been minimized.

omrsafetyo commented Aug 22, 2016

@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.

@MickyBalladelli

This comment has been minimized.

MickyBalladelli commented Aug 22, 2016

@omrsafetyo awesome post

@michael-o

This comment has been minimized.

michael-o commented Aug 22, 2016

@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.

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 22, 2016

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

@jkinz

This comment has been minimized.

jkinz commented Aug 22, 2016

@ 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.

@jkinz

This comment has been minimized.

jkinz commented Aug 22, 2016

@ rkeithhill

Very nice. :-)

@ShinNoNoir

This comment has been minimized.

ShinNoNoir commented Aug 22, 2016

@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.

@jkinz

This comment has been minimized.

jkinz commented Aug 22, 2016

@ 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.

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 22, 2016

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.

@giuliov

This comment has been minimized.

giuliov commented Aug 23, 2016

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.

@JohnMH

This comment has been minimized.

JohnMH commented Aug 23, 2016

@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.

@luisfarzati

This comment has been minimized.

luisfarzati commented Aug 24, 2016

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.

@Atomosk

This comment has been minimized.

Atomosk commented Aug 24, 2016

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

@AlManja

This comment has been minimized.

AlManja commented Aug 24, 2016

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

@infowolfe

This comment has been minimized.

infowolfe commented Aug 24, 2016

@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.

@luisfarzati

This comment has been minimized.

luisfarzati commented Aug 24, 2016

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.

@ShinNoNoir

This comment has been minimized.

ShinNoNoir commented Aug 24, 2016

@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?

@luisfarzati

This comment has been minimized.

luisfarzati commented Aug 24, 2016

@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
.

@omrsafetyo

This comment has been minimized.

omrsafetyo commented Aug 24, 2016

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.

@luisfarzati

This comment has been minimized.

luisfarzati commented Aug 24, 2016

@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.

@luisfarzati

This comment has been minimized.

luisfarzati commented Aug 24, 2016

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! :)

@thedaveking

This comment has been minimized.

thedaveking commented Aug 24, 2016

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

@justjanne

This comment has been minimized.

justjanne commented Aug 25, 2016

@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.

@luisfarzati

This comment has been minimized.

luisfarzati commented Aug 25, 2016

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.

@GeeLaw

This comment has been minimized.

GeeLaw commented Aug 25, 2016

@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.

@jpsnover

This comment has been minimized.

Contributor

jpsnover commented Aug 25, 2016

1127

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.

@lzybkr

This comment has been minimized.

Member

lzybkr commented Aug 25, 2016

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.

@PowerShell PowerShell locked and limited conversation to collaborators Aug 25, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.