initialsession: remove curl and wget aliases

[bagder]

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.

[msftclas]

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]

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.

[bagder]

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]

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]

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

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

[gevaerts]

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]

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

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

fine.

[lzybkr]

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]

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]

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]

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

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

[jpsnover]

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

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

[JohnMH]

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

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

[lzybkr]

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

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

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

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

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]

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

[jay]

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]

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]

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]

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]

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

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]

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]

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.

[gevaerts]

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]

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.

[codeape2]

How about implementing a "Remove-All-Aliases-That-Are-Linux-Commands" command that would do Remove-Item alias:curl alias:wget alias:ls alias:ps etc?

When starting powershell, the presence or absence of a command line switch could invoke this command automatically.

[omgbox]

i uninstalled windows and deleted my life

[nitin88]

It would be much better to keep consistency across platforms.
By continuing with this, the powershell adoption goes for toss in *nix

[senthilnayagam]

either microsoft users who use powershell alias for curl and wget are dumb or microsoft is dishonest

[Citillara]

Could those alias be disabled (not removed) by default ?
They could be enabled by either one of those

• Typing a command like "Enable-Linux-Aliases"
• Switch on starting up PowerShell
• OS Environment flag

[jaboutboul]

Guys, they are trying to do the right thing here, why don't we cut them some slack and work with them to arrive a solution that is sane and solves the problem instead of getting all vicious?

How these were implemented arose out of a culture that was totally averse to our community principles, which they are now clearly coming around to embracing after years of fighting it. Let's put our heads together and figure this out. This is also a learning exercise for Microsoft in governance of these types of projects. Both sides should be listening and mutually supportive.

[alekratz]

Before you start bashing Microsoft for making these decisions, remember that Powershell was never originally intended to be released for Linux. If you said Microsoft was going open source when Powershell was first released, you'd have been laughed out of the room.

Now, that being said, I like the idea of having an "Enable-Linux-Aliases" like @Citillara mentioned, to keep compatibility but still allowing Linux users to do their thing.

[charlieman]

Showing a warning to use Invoke-WebRequest or Remove-Item Alias:Curl could be a first step. Then you could remove or disable them in the next major version.

[kshmelkov]

remember that Powershell was never originally intended to be released for Linux.

So what? Is it a valid reason to shadow well-known software, windows versions of which are available for decades?

[bagder]

Powershell was never originally intended to be released for Linux

This was a problem already from the day they added these aliases. On Windows. Many years ago. This was just the first opportunity I had to actually try to do something about it.

curl has always worked fine on windows and did so many years before PowerShell even existed.

[simbalion]

This thread shows that Microsoft is dysfunctional.

Whether Powershell was intended to be released for Linux is irrelevant, you do not create programs which intentionally have the same names as well known programs, especially when your programs do not provide exactly the same functionality as the originals. There is no way to view that sort of behavior in a positive light.

Further, the bureaucracy that makes this a lengthy conversation instead of a simple "oops, you're right, let us fix that today" is laughable. "corporate governance" and whatever, good sense has gone out the window.

That is the reason the Microsoft product empire is suffering. The competition does not suffer from these dysfunctions.

[alekratz]

@traverseda I don't think the "embrace, extend, extinguish" doctrine is a fair assessment of this situation. Those were the business practices of Microsoft 10+ years ago, to take over entire corporations. Are they doing it here? Possibly, but unlikely. But they have not embraced, extended, nor extinguished in a long time. I implore you to find an example of this behavior in the past ten years. I'm not trying to make this about computer company politics, and it would be foolish for anyone so deeply involved in open source to welcome Microsoft with open, trusting arms. They have been known to bite, and open source has (and still is) been bitten before. But bringing up company politics does not address the technical issue at hand.

There's been a lot of unproductive Microsoft bashing in this thread. Sorry to call you out specifically, but I'm really more interested in reading about solutions to this problem rather than getting angry at the original developer.

[small1]

@alekratz this is not a Linux problem. This is a problem on Windows at the moment and will be on all the others is the aliases is not removed. I did battle this on Windows machines. If you are used to curl on other platforms and you start using it on windows. Ending up with invoke-webrequest is very confusing.

[alekratz]

@small1 thanks for clearing that up. I still think it's a relatively good solution to preserve functionality; albeit broken functionality.

[traverseda]

@alekratz

Fair enough. I was trying to explain where some of this hostility was coming from, as someone who participates in the open source community.

But it definitely wasn't making things less hostile in here. I've retracted the comment.

I still think that this is, at least in curls case, a bit potential trademark issue.

[agilob]

@alekratz Completely agree, but I'm sure they didn't make the decision on open-sourcing it in one day, they took a lot of preparations and it's just strange that such fundamental programs like curl and wget were not tested. And as @bagder says, if that's old issue with PowerShell, I'm sure @jpsnover or others at MS were aware of it.

[waynebloss]

Half the people here are just haters and you're stinking up the place. Go away. You're not here to use PowerShell, so what do you care?

[kilasuit]

We can't change what decisions were made in the past - no matter how much we want to and bring good reasons to the table about how ill conceived a thought it has now become to have done it - If I had been involved back then (though was blissfully unaware of PowerShell, curl and a considerable amount of IT at the time) and as a lot of you guys have mentioned as well i would have opposed it as it makes for a now poor UX for anyone used to curl & the *nix aliases

Though if your writing a script to be used on someone elses machine you can place any code like

cd Alias:\ ; Remove-item curl,wget

Right at the beginning of the script which stops the issue.

That said the team have put the governance in place for the right reasons and this is still only the first 24 hours of this repo being public so there will be things like this that The PowerShell Team will need to evaluate in bigger depth for the wider perspective other than this seemingly small change.

Also remember this is very new territory for Microsoft full stop so there are going to be inherent bumps in the initial weeks & months whilst there is adaptation to it.

Things like this from the older releases will also be easily missed whilst newer stuff is fresher in the memory.

I for one though am really excited to see all the enthusiasm even with the difference in opinions and hope that continues beyond this change.

[Secretmapper]

@trumbitta Where did they say they won't play ball? What their saying is a discussion should be started around it, which should happen anyway in any sort of breaking change. It sort of confuses me that developers are bashing microsoft for this, you'd think developers would be the ones that would understand most of this.

Can we please keep the discussion civil and move forward with discussing solutions? The suggestion of having a "Remove-All-Aliases-That-Are-Linux-Commands" command seems to be the easiest and straightforward solution to this (with the aliased linux commands later being deprecated)

[rafa2000]

This is how embracing and extinguishing Linux/Unix works. Just hijack all command names accumulated for more than 40 years in the body and soul of the Unix system. What should be next, what would do most damage to users that are for the first time looking to use Windows as another quasi Unix machine. How about cut, grep, diff, find? The solution using 'Remove Item-Alias:curl' and 'Remove Item-Alias:wget' are the most appropiate to fix it temporarily, but it should be the other way around, like: 'Add Item-Alias:wget:microsoft-wget' if we need to add commands replaced, in a honest way, by Microsoft. Thanks and please disregard any words that seem harsh.

[ShinNoNoir]

Not sure if this is useful, but here's a variation on using the call operator, but packaged more nicely:

function Run-Application() {
    $app, $params = $args
    & (Get-Command -CommandType Application $app) $params
}

Set-Alias run Run-Application

PS C:\tmp> run wget http://google.com -O google.html
--21:09:12--  http://google.com/
           => `google.html'
Resolving google.com... done.
Connecting to google.com[82.94.228.159]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.nl/?gfe_rd=cr&ei=V_y5V-3QMa3H8AfuiIHgBw [following]
--21:09:12--  http://www.google.nl/?gfe_rd=cr&ei=V_y5V-3QMa3H8AfuiIHgBw
           => `google.html'
Resolving www.google.nl... done.
Connecting to www.google.nl[74.125.136.94]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [ <=>                                 ] 11,221        10.70M/s

21:09:12 (10.70 MB/s) - `google.html' saved [11221]

[bluefoxicy]

@kuldeepdhaka Well I had my say, and you just stonewalled me and claim I'm wrong. I want my say stamps foot I'm right I'm right stop saying I'm wrong!!!!

.... no?

Closed WONTFIX reason USERISANIDIOT.

So much for having a say.

We blog about people we don't like. We all have a say because we get online and we cry to the world that some closed-source, proprietary company isn't listening to our desires. We're all part of a community there, too.

Yes, they can pay someone else with reasonable charge.

Can minimum-wage workers pay someone else to customize software to their needs? They make $14,000/year and spend most of it on survival, and beg food off people to live.

[kuldeepdhaka]

@bluefoxicy

Can minimum-wage workers pay someone else to customize software to their needs? They make $14,000/year and spend most of it on survival, and beg food off people to live.

Someone else who has money can pay for the changes that fixes some minimum-wage worker.
And contribute it back to community. that way everyone get the benifit.
Now, ALL minimum wage worker with the same problem get the problem solved.

Also, the poor and rich divide is majorly due explotation than "being-innovative".

Also if practicality is considered,
minimum wage worker first need to fullfill their primary requirement before going to secondary/terniary.

[bwatts]

@johnmharrisjr

I have no use for PowerShell, because I have bash installed on my system.

This is a lot of drama from someone with no investment. Where does that energy come from?

[kuldeepdhaka]

you just stonewalled me

@bluefoxicy You want me to see from your (imagination) window, i will NOT!
I just pointed out the loop-holes/wrongs in your thinking/thoughts from my POV.

[JohnMH]

@bwatts I don't understand what you mean by "no investment". You don't have to use software to contribute to its betterment.

[bwatts]

@johnmharrisjr I suppose it means, "why do you care beyond the tautology of caring?" The decisions made here will have zero impact on your life, aside from the thrill of the chase.

[JohnMH]

@bwatts The decisions made here don't directly impact me, but I have to work with people who use PowerShell and I would appreciate it if they didn't get confused when they try to use curl from PowerShell. I'm in it for the end users, not myself.

[bwatts]

Cool beans. Altruism and cause-junkie-ism suffer from Poe's Law so I'll have to assume your intentions are rooted in the experiences of others and not in a desire to be right on the Internet.

[JohnMH]

@bwatts Would it help to add or remove "winkie faces and random emoji"?

[jkinz]

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

[jkinz]

@jpsnover

What is the commonly accepted open source practice for introducing a breaking change on a billion machines?

The first accepted practice is to not design it so it breaks when you start distributing it to a global, or more global user population.

Since PS was never originally intended to be that widely used it's somewhat understandable that no one was concerned about the namespace collision.

But given that the collision has happened, the resolution is clear, and common: correct the issue in the smaller scope, that is - remove the alias from PS and then Ship a convert script to fix all the scripts that use the aliases.

Like this:

for f in $( find . -name *.ps ); do sed -i -e 's/wget/ web object request string/g' $f; done

And do the same for the other alias. (Note - this example uses GNU sed. )

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

[ShinNoNoir]

@jkinz

Like this:
for f in $( find . -name *.ps ); do sed -i -e 's/wget/ web object request string/g' $f; done
And do the same for the other alias. (Note - this example uses GNU sed. )

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?

$SRC = "http://downloads.sourceforge.net/project/gnuwin32/wget/1.11.4-1/wget-1.11.4-1-bin.zip?r=&ts=1471838991&use_mirror=netcologne"
$DST = "$env:temp/wget-bin.zip"

Invoke-WebRequest $SRC -OutFile $DST

[GeeLaw]

@Citillara

Could those alias be disabled (not removed) by default ? They could be enabled by either one of those

• Typing a command like "Enable-Linux-Aliases"
• Switch on starting up PowerShell
• OS Environment flag

These aliases does not exist when you're not using Windows PowerShell, so when you use PowerShell for Unix/Linux the problem does not exist. For backward compatibility, Windows user should opt OUT of Unix/Linux aliases. Therefore we should really introduce Disable-UnixAliases.

[GeeLaw]

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.

[rkeithhill]

@jkinz No need to attempt this search/replace operation with regex. PowerShell supplies a parser for PowerShell script which returns an AST that you can then work with. Then you know when you're replacing commands instead of comments or terms in a string. I don't claim the following PowerShell script is bug free but it will give you an idea of what's possible:

$script = @'

    $webReq = wget http://foo.com

    $SRC = "http://downloads.sourceforge.net/project/gnuwin32/wget/1.11.4-1/wget-1.11.4-1-bin.zip?r=&ts=1471838991&use_mirror=netcologne"
    $DST = "$env:temp/wget-bin.zip"

    Invoke-WebRequest $SRC -OutFile $DST

    $webReq = wget https://github.com
    $webReq.Content[0..100]
}
'@

# Parse the script
$errs = $tokens = $null
$ast = [System.Management.Automation.Language.Parser]::ParseInput($script, [ref]$tokens, [ref]$errs)

# Look in the AST for all commands
$commands = $ast.FindAll({
    param($Ast)
    if ($Ast -isnot [System.Management.Automation.Language.CommandAst]) {
        return $false
    }
    if ($Ast.DefiningKeyword) {
        return $false
    }

    return ($null -ne $Ast.GetCommandName())
}, $true)

"*" * 80
"Script before: " + $script

$scriptText = [System.Text.StringBuilder]::new($script)

# Replace each alias with its resolved command name
for ($i = $commands.Count - 1; $i -ge 0 ; $i--) {
    $command = $commands[$i]
    $commandName = $command.GetCommandName()
    $aliasInfo = Get-Alias | Where-Object {$_.Name -eq $commandName}
    if ($null -ne $aliasInfo) {
        $commandElement = $command.CommandElements | Where-Object Value -eq $commandName
        $extent = $commandElement.Extent
        $length = $extent.EndOffset - $extent.StartOffset

        $scriptText.Remove($extent.StartOffset, $length) > $null
        $scriptText.Insert($extent.StartOffset, $aliasInfo.ResolvedCommand.Name) > $null
    }
}

"*" * 80
"Script after: " + $scriptText.ToString()

This will change the original script to:

********************************************************************************
Script after: 
    $webReq = Invoke-WebRequest http://foo.com

    $SRC = "http://downloads.sourceforge.net/project/gnuwin32/wget/1.11.4-1/wget-1.11.4-1-bin.zip?r=&ts=1471838991&use_mirror=netcologne"
    $DST = "$env:temp/wget-bin.zip"

    Invoke-WebRequest $SRC -OutFile $DST

    $webReq = Invoke-WebRequest https://github.com
    $webReq.Content[0..100]
}

[ShinNoNoir]

@rkeithhill
That is definitely a better solution.

(It would break though if a script would heavily rely on evaluating strings to do some computation, like in the example below, but that's such a corner case and an example of really, really bad coding practices.)

$evil = "wget"
$webReq = & $evil https://github.com

function moreEvil() { "wget" }
$webReq = & (iex moreEvil) https://github.com

[michael-o]

Business as usual, Microsoft broke other people's stuff and now they are rejecting to fix that. History repeats.

[torgro]

@michael-o Business as usual, Linux users still regret that they did not come up with objects in the pipeline and are still struggling with bash-ing text. That being said, you are really good at it! 👍

They are starting a RFC and they have "rejected" the PR for the time being. If you had a billion potential users relying on your product, you should take great care before introducing breaking changes. I am confident that @jpsnover will find a solution and share it with the community.

@BiIIGates What a lovely trick 👍

Now, do some good, start fixing Powershell bugs (if you can find them) and create PR!

[lfckop]

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

[JohnMH]

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]

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]

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

[GeeLaw]

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]

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

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]

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

[JohnMH]

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]

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

Cheers!

[JohnMH]

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

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

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

@omrsafetyo awesome post

[michael-o]

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

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

[jkinz]

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

@ rkeithhill

Very nice. :-)

[ShinNoNoir]

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

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

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]

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]

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

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]

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

[AlManja]

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]

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

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]

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

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

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]

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

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]

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

[justjanne]

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

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

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]

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.