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

Show comment
Hide comment
@msftclas

msftclas 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;

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 18, 2016

Member

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.

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.

Show comment
Hide comment
@bagder

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

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.

Show comment
Hide comment
@joeyaiello

joeyaiello Aug 18, 2016

Member

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.

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 18, 2016

Contributor

@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

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 18, 2016

Contributor

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

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.

Show comment
Hide comment
@gevaerts

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

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 18, 2016

Contributor

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

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.

Show comment
Hide comment
@gevaerts

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

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 18, 2016

Contributor

fine.

Contributor

jpsnover commented Aug 18, 2016

fine.

@lzybkr

This comment has been minimized.

Show comment
Hide comment
@lzybkr

lzybkr Aug 18, 2016

Member

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.

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.

Show comment
Hide comment
@tomer

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

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.

Show comment
Hide comment
@JohnMH

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

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.

Show comment
Hide comment
@joshka

joshka 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

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.

Show comment
Hide comment
@JohnMH

JohnMH Aug 19, 2016

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

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 19, 2016

Contributor

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

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.

Show comment
Hide comment
@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

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

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 19, 2016

Contributor

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

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 19, 2016

Member

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

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.

Show comment
Hide comment
@JohnMH

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

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 19, 2016

Member

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

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.

Show comment
Hide comment
@JohnMH

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

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.

Show comment
Hide comment
@jay

jay 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

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.

Show comment
Hide comment
@JohnMH

JohnMH Aug 19, 2016

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

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.

Show comment
Hide comment
@jay

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

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.

Show comment
Hide comment
@JohnMH

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

@kilasuit

This comment has been minimized.

Show comment
Hide comment
@kilasuit

kilasuit Aug 19, 2016

Contributor

You adding them was "a breaking change" to people who were used to using curl and wget from their command lines.

As much as I can see how to some the curl and wget aliases can be seem as a "breaking" change the but the decision to implement them was as a gateway for those that had not picked up PowerShell back in 2009 (7 years ago now) when it was released in PowerShell version 3 along with the aliases that are also used as standard from psv1 days aka from 2006.

However we have these aliases and others and we will need to collectively make the right decision on how these get dealt with which IMO going through the RFC process is the right way to do it.

From experience in dealing with Windows SysAdmins there are many less that out there that actually share their scripts so relying on a google search to get examples is not something that I would say gives that much credibility to the argument being made.

That said however I do agree that the aliases for curl and wget should be removed from PowerShell completely but that's because I don't agree with aliases being able to be used other than interactively.

Generally however it is recommended in scripts not to use aliases at all and this is why the PowerShell ScriptAnalyzer (which everyone should start to use if not already being used see https://github.com/PowerShell/PSScriptAnalyzer ) has a rule that picks up on the use of aliases and warns the user not to use them. When I present and teach I Always warn about the use of aliases even for .exe applications because of issues like this and only suggest use of them in interactive sessions.

Contributor

kilasuit commented Aug 19, 2016

You adding them was "a breaking change" to people who were used to using curl and wget from their command lines.

As much as I can see how to some the curl and wget aliases can be seem as a "breaking" change the but the decision to implement them was as a gateway for those that had not picked up PowerShell back in 2009 (7 years ago now) when it was released in PowerShell version 3 along with the aliases that are also used as standard from psv1 days aka from 2006.

However we have these aliases and others and we will need to collectively make the right decision on how these get dealt with which IMO going through the RFC process is the right way to do it.

From experience in dealing with Windows SysAdmins there are many less that out there that actually share their scripts so relying on a google search to get examples is not something that I would say gives that much credibility to the argument being made.

That said however I do agree that the aliases for curl and wget should be removed from PowerShell completely but that's because I don't agree with aliases being able to be used other than interactively.

Generally however it is recommended in scripts not to use aliases at all and this is why the PowerShell ScriptAnalyzer (which everyone should start to use if not already being used see https://github.com/PowerShell/PSScriptAnalyzer ) has a rule that picks up on the use of aliases and warns the user not to use them. When I present and teach I Always warn about the use of aliases even for .exe applications because of issues like this and only suggest use of them in interactive sessions.

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

JohnMH Aug 19, 2016

While I don't agree with you about aliases being used non interactively (see bash's handling of aliases), I do agree that completely removing them would be beneficial to everyone. The inclusion of these "aliases" is confusing to users who mean to use curl or wget.

On August 18, 2016 11:40:56 PM EDT, Ryan Yates notifications@github.com wrote:

You adding them was "a breaking change" to people who were used to
using curl and wget from their command lines.

As much as I can see how to some the curl and wget aliases can be seem
as a "breaking" change the but the decision to implement them was as a
gateway for those that had not picked up PowerShell back in 2009 (7
years ago now) when it was released in PowerShell version 3 along with
the aliases that are also used as standard from psv1 days aka from
2006.

However we have these aliases and others and we will need to
collectively make the right decision on how these get dealt with which
IMO going through the RFC process is the right way to do it.

From experience in dealing with Windows SysAdmins there are many less
that out there that actually share their scripts so relying on a google
search to get examples is not something that I would say gives that
much credibility to the argument being made.

That said however I do agree that the aliases for curl and wget should
be removed from PowerShell completely but that's because I don't agree
with aliases being able to be used other than interactively.

Generally however it is recommended in scripts not to use aliases
at all and this is why the PowerShell ScriptAnalyzer (which everyone
should start to use if not already being used see
https://github.com/PowerShell/PSScriptAnalyzer ) has a rule that picks
up on the use of aliases and warns the user not to use them. When I
present and teach I Always warn about the use of aliases even for
.exe applications because of issues like this and only suggest use of
them in interactive sessions.

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented Aug 19, 2016

While I don't agree with you about aliases being used non interactively (see bash's handling of aliases), I do agree that completely removing them would be beneficial to everyone. The inclusion of these "aliases" is confusing to users who mean to use curl or wget.

On August 18, 2016 11:40:56 PM EDT, Ryan Yates notifications@github.com wrote:

You adding them was "a breaking change" to people who were used to
using curl and wget from their command lines.

As much as I can see how to some the curl and wget aliases can be seem
as a "breaking" change the but the decision to implement them was as a
gateway for those that had not picked up PowerShell back in 2009 (7
years ago now) when it was released in PowerShell version 3 along with
the aliases that are also used as standard from psv1 days aka from
2006.

However we have these aliases and others and we will need to
collectively make the right decision on how these get dealt with which
IMO going through the RFC process is the right way to do it.

From experience in dealing with Windows SysAdmins there are many less
that out there that actually share their scripts so relying on a google
search to get examples is not something that I would say gives that
much credibility to the argument being made.

That said however I do agree that the aliases for curl and wget should
be removed from PowerShell completely but that's because I don't agree
with aliases being able to be used other than interactively.

Generally however it is recommended in scripts not to use aliases
at all and this is why the PowerShell ScriptAnalyzer (which everyone
should start to use if not already being used see
https://github.com/PowerShell/PSScriptAnalyzer ) has a rule that picks
up on the use of aliases and warns the user not to use them. When I
present and teach I Always warn about the use of aliases even for
.exe applications because of issues like this and only suggest use of
them in interactive sessions.

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

@joshka

This comment has been minimized.

Show comment
Hide comment
@joshka

joshka Aug 19, 2016

@JohnMHarrisJr I agree with you 100%, the aliases are wrong. That said removing them will break a bunch of scripts. I've shown you one public shared script, but there's likely significantly more that are not shared on github. I know I've written at least one script that's sitting on a client's machine somewhere over the years. Removing this code per the PR will break those scripts. Something like removing that code but adding it to a default profile script might be a better fix (but that likely comes with its own problems). An RFC is appropriate here. Being that it's been broken for 7 odd years, taking the time to fix it properly is unlikely to cause anyone any significant damage wouldn't you say?

joshka commented Aug 19, 2016

@JohnMHarrisJr I agree with you 100%, the aliases are wrong. That said removing them will break a bunch of scripts. I've shown you one public shared script, but there's likely significantly more that are not shared on github. I know I've written at least one script that's sitting on a client's machine somewhere over the years. Removing this code per the PR will break those scripts. Something like removing that code but adding it to a default profile script might be a better fix (but that likely comes with its own problems). An RFC is appropriate here. Being that it's been broken for 7 odd years, taking the time to fix it properly is unlikely to cause anyone any significant damage wouldn't you say?

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

JohnMH Aug 19, 2016

From the sheer number of workarounds and misuses of the curl command in Powershell scripts on GitHub alone, I'd say that more scripts are broken now than would otherwise be "broken" by removing these aliases.

I can't speak for Windows sysadmins, but on GNU/Linux systems (I've had a lot of experience with Red Hat Enterprise Linux and CentOS machines personally, managed mostly with Ansible now) when an update comes out that changes options in a command to the point that something breaks two things happen:

  1. Things break, obviously. When things stop working we look at the output of Cron jobs and do a full triage of our code that's supposed to be working, that's a sysadmin's job.

  2. There's an option to not update if we know it'll break stuff and we're too lazy to fix it.

If somebody is actively updating machines, then somebody can definitely see error logs on the machines they're updating, especially in the case of Windows machines, where updates are such a pain.

On August 18, 2016 11:49:17 PM EDT, Joshua McKinney notifications@github.com wrote:

@JohnMHarrisJr I agree with you 100%, the aliases are wrong. That said
removing them will break a bunch of scripts. I've shown you one public
shared script, but there's likely significantly more that are not
shared on github. I know I've written at least one script that's
sitting on a client's machine somewhere over the years. Removing this
code per the PR will break those scripts. Something like removing that
code but adding it to a default profile script might be a better fix
(but that likely comes with its own problems). An RFC is appropriate
here. Being that it's been broken for 7 odd years, taking the time to
fix it properly is unlikely to cause anyone any significant damage
wouldn't you say?

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented Aug 19, 2016

From the sheer number of workarounds and misuses of the curl command in Powershell scripts on GitHub alone, I'd say that more scripts are broken now than would otherwise be "broken" by removing these aliases.

I can't speak for Windows sysadmins, but on GNU/Linux systems (I've had a lot of experience with Red Hat Enterprise Linux and CentOS machines personally, managed mostly with Ansible now) when an update comes out that changes options in a command to the point that something breaks two things happen:

  1. Things break, obviously. When things stop working we look at the output of Cron jobs and do a full triage of our code that's supposed to be working, that's a sysadmin's job.

  2. There's an option to not update if we know it'll break stuff and we're too lazy to fix it.

If somebody is actively updating machines, then somebody can definitely see error logs on the machines they're updating, especially in the case of Windows machines, where updates are such a pain.

On August 18, 2016 11:49:17 PM EDT, Joshua McKinney notifications@github.com wrote:

@JohnMHarrisJr I agree with you 100%, the aliases are wrong. That said
removing them will break a bunch of scripts. I've shown you one public
shared script, but there's likely significantly more that are not
shared on github. I know I've written at least one script that's
sitting on a client's machine somewhere over the years. Removing this
code per the PR will break those scripts. Something like removing that
code but adding it to a default profile script might be a better fix
(but that likely comes with its own problems). An RFC is appropriate
here. Being that it's been broken for 7 odd years, taking the time to
fix it properly is unlikely to cause anyone any significant damage
wouldn't you say?

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

@kilasuit

This comment has been minimized.

Show comment
Hide comment
@kilasuit

kilasuit Aug 19, 2016

Contributor

Some of the painful history with PowerShell however is due to it having been coupled into the OS but not a product that really received "Updates" like we get for other OS components (at least that I can remember) other than the WMF updates that would install a newer version of WMF (and inherently PowerShell too)

So this issue could have potentially been mitigated by there being actual updates for powershell shipped in a manner other than via WMF major versions however that ship has long been sunk so we have to deal with the fallout.

However now that the Release cadence has been decoupled from Windows OS (or will be in future) which can only be a good thing right?

Contributor

kilasuit commented Aug 19, 2016

Some of the painful history with PowerShell however is due to it having been coupled into the OS but not a product that really received "Updates" like we get for other OS components (at least that I can remember) other than the WMF updates that would install a newer version of WMF (and inherently PowerShell too)

So this issue could have potentially been mitigated by there being actual updates for powershell shipped in a manner other than via WMF major versions however that ship has long been sunk so we have to deal with the fallout.

However now that the Release cadence has been decoupled from Windows OS (or will be in future) which can only be a good thing right?

@small1

This comment has been minimized.

Show comment
Hide comment
@small1

small1 Aug 19, 2016

Well. Aliases like these if you come from the unix world would never have been built in.

They break stuff and creates an amount of weirdness and forces many users to use workarounds like this: http://superuser.com/questions/883914/how-do-i-permanently-remove-a-default-powershell-alias

I use that on a couple of machines but that also means that my scripts wont work on others unless they do the same. And stuff like this also creates guides like this: http://www.powertheshell.com/bp_script_alias/ that says dont use aliases in scripts. And that is what i prefer myself. That way a script always works regardless of what machine i use it on.

small1 commented Aug 19, 2016

Well. Aliases like these if you come from the unix world would never have been built in.

They break stuff and creates an amount of weirdness and forces many users to use workarounds like this: http://superuser.com/questions/883914/how-do-i-permanently-remove-a-default-powershell-alias

I use that on a couple of machines but that also means that my scripts wont work on others unless they do the same. And stuff like this also creates guides like this: http://www.powertheshell.com/bp_script_alias/ that says dont use aliases in scripts. And that is what i prefer myself. That way a script always works regardless of what machine i use it on.

ooxi added a commit to ooxi/poweretcd that referenced this pull request Aug 19, 2016

Use Invoke-WebRequest instead of curl
`curl` is a PowerShell alias for `Invoke-WebRequest`. There is [currently a discussion](PowerShell/PowerShell#1901) about removing those aliases.
@gevaerts

This comment has been minimized.

Show comment
Hide comment
@gevaerts

gevaerts Aug 19, 2016

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.

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.

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.

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.

@kylecordes

This comment has been minimized.

Show comment
Hide comment
@kylecordes

kylecordes Aug 19, 2016

Looking back near the start of this thread, I'm reminded of one of the big challenges and unintended side effects of otherwise responsible project governance. The default result, and the case here, is that governance processes lock in early ill-considered decisions made in isolation, and strongly privilege the input of the people who made them over the input of people who come along later in a project with potentially much better quality input. I don't have a solution to this problem, acknowledging that it exists.

Looking back near the start of this thread, I'm reminded of one of the big challenges and unintended side effects of otherwise responsible project governance. The default result, and the case here, is that governance processes lock in early ill-considered decisions made in isolation, and strongly privilege the input of the people who made them over the input of people who come along later in a project with potentially much better quality input. I don't have a solution to this problem, acknowledging that it exists.

@lfckop

This comment has been minimized.

Show comment
Hide comment
@lfckop

lfckop Aug 22, 2016

@jpsnover, I'm very sorry, and I deleted the comment.

lfckop commented Aug 22, 2016

@jpsnover, I'm very sorry, and I deleted the comment.

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

JohnMH Aug 22, 2016

This "precaution" is ridiculous. If somebody has the ability to change your PATH, they can also do many other things and you've already, as the saying goes, screwed the pooch.

It doesn't matter, I suppose. The better question is this: What exactly is the exact path to curl on Windows? I've never seen anything installed in a predictable location.

On August 21, 2016 7:08:47 PM EDT, jkinz notifications@github.com wrote:

@ShinNoNoir

@jkinz

Then quoting you from an earlier post:

Commands should be invoked by pathname.

Nothing needs to be fixed then? If you want to use wget or curl,
invoke it by their full path, since, hey, this is the obvious way to do
it?

In a script? yes, that is the best practice. Otherwise there is a
security vulnerability that someone can place a same-named executable
on the $PATH and that false executable will be executed instead of the
one you intended. (But you knew that already... )

Some people (OK many people) save keystrokes by placing the full path
in a variable and invoking it indirectly.

WGET="/usr/bin/wget"

This is another best practice. If your scripts are being used by
other people in a production environment, you should consider these
precautions mandatory.

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented Aug 22, 2016

This "precaution" is ridiculous. If somebody has the ability to change your PATH, they can also do many other things and you've already, as the saying goes, screwed the pooch.

It doesn't matter, I suppose. The better question is this: What exactly is the exact path to curl on Windows? I've never seen anything installed in a predictable location.

On August 21, 2016 7:08:47 PM EDT, jkinz notifications@github.com wrote:

@ShinNoNoir

@jkinz

Then quoting you from an earlier post:

Commands should be invoked by pathname.

Nothing needs to be fixed then? If you want to use wget or curl,
invoke it by their full path, since, hey, this is the obvious way to do
it?

In a script? yes, that is the best practice. Otherwise there is a
security vulnerability that someone can place a same-named executable
on the $PATH and that false executable will be executed instead of the
one you intended. (But you knew that already... )

Some people (OK many people) save keystrokes by placing the full path
in a variable and invoking it indirectly.

WGET="/usr/bin/wget"

This is another best practice. If your scripts are being used by
other people in a production environment, you should consider these
precautions mandatory.

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

JohnMH Aug 22, 2016

Wait, it's a string and therefore suffers encoding issues? How did that happen?.. Perhaps something should be learned from every modern shell dating back to bash..

On August 22, 2016 12:58:59 AM EDT, Gee Law notifications@github.com wrote:

In reply to @JohnMHarrisJr

Sure, but what, on Windows, is the always-consistent path to curl?
And why does one have to write the full path, anyway? Isn't that why
the PATH variable exists, to make looking for software easier?

Since curl.exe should not be used in PowerShell pipes (as it is a
native tool, which outputs string in PowerShell, and suffer from
encoding issues), the best practice is to

Start-Process curl -Arguments @(...) -RedirectStandardInput ...
-RedirectStandardOutput ... -Wait -NoNewWindow;
# Use `start` if you are in an interactive session.

And then use the output file with custom encoding/format. It is also a
best practice not to use aliases in scripts, but this is not generally
followed.

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented Aug 22, 2016

Wait, it's a string and therefore suffers encoding issues? How did that happen?.. Perhaps something should be learned from every modern shell dating back to bash..

On August 22, 2016 12:58:59 AM EDT, Gee Law notifications@github.com wrote:

In reply to @JohnMHarrisJr

Sure, but what, on Windows, is the always-consistent path to curl?
And why does one have to write the full path, anyway? Isn't that why
the PATH variable exists, to make looking for software easier?

Since curl.exe should not be used in PowerShell pipes (as it is a
native tool, which outputs string in PowerShell, and suffer from
encoding issues), the best practice is to

Start-Process curl -Arguments @(...) -RedirectStandardInput ...
-RedirectStandardOutput ... -Wait -NoNewWindow;
# Use `start` if you are in an interactive session.

And then use the output file with custom encoding/format. It is also a
best practice not to use aliases in scripts, but this is not generally
followed.

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

@jpsnover

This comment has been minimized.

Show comment
Hide comment
@jpsnover

jpsnover Aug 22, 2016

Contributor

@johnMHarrisJr quick Q - what is your level of PowerShell usage/expertise and what do you use it for?

Contributor

jpsnover commented Aug 22, 2016

@johnMHarrisJr quick Q - what is your level of PowerShell usage/expertise and what do you use it for?

@GeeLaw

This comment has been minimized.

Show comment
Hide comment
@GeeLaw

GeeLaw Aug 22, 2016

In reply to @JohnMHarrisJr

Wait, it's a string and therefore suffers encoding issues? How did that happen?.. Perhaps something should be learned from every modern shell dating back to bash..

AFAIK bash doesn't do anything to the pipeline stream. It's up to each utility to understand the encoding etc (i.e., the pipe is binary). In PowerShell (till 5.0) there is not a "raw binary" pipeline and anything from/to a native utility is a string. In my experience, PowerShell does not work well with UTF8 w/o BOM.

GeeLaw commented Aug 22, 2016

In reply to @JohnMHarrisJr

Wait, it's a string and therefore suffers encoding issues? How did that happen?.. Perhaps something should be learned from every modern shell dating back to bash..

AFAIK bash doesn't do anything to the pipeline stream. It's up to each utility to understand the encoding etc (i.e., the pipe is binary). In PowerShell (till 5.0) there is not a "raw binary" pipeline and anything from/to a native utility is a string. In my experience, PowerShell does not work well with UTF8 w/o BOM.

@jpsnover

This comment has been minimized.

Show comment
Hide comment
@jpsnover

jpsnover Aug 22, 2016

Contributor

@lfckop np. I suspect you are correct but we just don't have the data and experience shows that when you have a billion users, a very large group of people use all the edge cases. :-(

Contributor

jpsnover commented Aug 22, 2016

@lfckop np. I suspect you are correct but we just don't have the data and experience shows that when you have a billion users, a very large group of people use all the edge cases. :-(

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

JohnMH Aug 22, 2016

I have never used PowerShell, but I understand the concept. I do not use PowerShell now nor do I plan to any time soon.

On August 22, 2016 10:45:45 AM EDT, Jeffrey Snover notifications@github.com wrote:

@johnMHarrisJr quick Q - what is your level of PowerShell
usage/expertise and what do you use it for?

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented Aug 22, 2016

I have never used PowerShell, but I understand the concept. I do not use PowerShell now nor do I plan to any time soon.

On August 22, 2016 10:45:45 AM EDT, Jeffrey Snover notifications@github.com wrote:

@johnMHarrisJr quick Q - what is your level of PowerShell
usage/expertise and what do you use it for?

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

@jpsnover

This comment has been minimized.

Show comment
Hide comment
@jpsnover

jpsnover Aug 22, 2016

Contributor

@johnMHarrisJr. Np. That helps calibrate the input. Thanks for providing input to make PowerShell great

Contributor

jpsnover commented Aug 22, 2016

@johnMHarrisJr. Np. That helps calibrate the input. Thanks for providing input to make PowerShell great

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

JohnMH Aug 22, 2016

I don't think that is enough to understand my background. I don't use PowerShell, but I understand it to the point that I can help others with simple things and I do work with people who do use it. I don't have any Windows machines, so I haven't had a use for PowerShell.

On August 22, 2016 11:10:24 AM EDT, Jeffrey Snover notifications@github.com wrote:

@johnMHarrisJr. Np. That helps calibrate the input. Thanks for
providing input to make PowerShell great

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented Aug 22, 2016

I don't think that is enough to understand my background. I don't use PowerShell, but I understand it to the point that I can help others with simple things and I do work with people who do use it. I don't have any Windows machines, so I haven't had a use for PowerShell.

On August 22, 2016 11:10:24 AM EDT, Jeffrey Snover notifications@github.com wrote:

@johnMHarrisJr. Np. That helps calibrate the input. Thanks for
providing input to make PowerShell great

John M. Harris, Jr.
PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

@jpsnover

This comment has been minimized.

Show comment
Hide comment
@jpsnover

jpsnover Aug 22, 2016

Contributor

@johnMHarrisJr. Well there's nothing holding you back now that we're on Linux. :-). Give it a try. You might like it.

Cheers!

Contributor

jpsnover commented Aug 22, 2016

@johnMHarrisJr. Well there's nothing holding you back now that we're on Linux. :-). Give it a try. You might like it.

Cheers!

@JohnMH

This comment has been minimized.

Show comment
Hide comment
@JohnMH

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

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 22, 2016

Member

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

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.

Show comment
Hide comment
@omrsafetyo

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

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

Show comment
Hide comment

@omrsafetyo awesome post

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o 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.

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 22, 2016

Member

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

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.

Show comment
Hide comment
@jkinz

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

Show comment
Hide comment
@jkinz

jkinz Aug 22, 2016

@ rkeithhill

Very nice. :-)

jkinz commented Aug 22, 2016

@ rkeithhill

Very nice. :-)

@ShinNoNoir

This comment has been minimized.

Show comment
Hide comment
@ShinNoNoir

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

Show comment
Hide comment
@jkinz

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

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 22, 2016

Member

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.

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.

Show comment
Hide comment
@giuliov

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

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.

Show comment
Hide comment
@JohnMH

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

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.

Show comment
Hide comment
@luisfarzati

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

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.

Show comment
Hide comment
@Atomosk

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

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.

Show comment
Hide comment
@AlManja

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

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.

Show comment
Hide comment
@infowolfe

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

Show comment
Hide comment
@luisfarzati

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

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.

Show comment
Hide comment
@ShinNoNoir

ShinNoNoir 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

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.

Show comment
Hide comment
@luisfarzati

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

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.

Show comment
Hide comment
@omrsafetyo

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

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.

Show comment
Hide comment
@luisfarzati

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

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

Show comment
Hide comment
@luisfarzati

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

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.

Show comment
Hide comment
@thedaveking

thedaveking Aug 24, 2016

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

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

@justjanne

This comment has been minimized.

Show comment
Hide comment
@justjanne

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

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.

Show comment
Hide comment
@luisfarzati

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

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.

Show comment
Hide comment
@GeeLaw

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

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.

Show comment
Hide comment
@jpsnover

jpsnover Aug 25, 2016

Contributor

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.

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.

Show comment
Hide comment
@lzybkr

lzybkr Aug 25, 2016

Member

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.

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.