I kind of feel sorry for the MS chaps here. They admit it's wrong, say they will try to fix it but it'll take time because of bureaucracy. But then they get attacked in the thread because they are Microsoft. It's sad to see when they are generally trying.
Why do people call structured governance a bureaucracy? About a month ago there was a well received post on GTK's rotten foundations that boils down to several core points, one of them being: if you keep breaking stuff all the time, there's no point in investing in your API.
And here we are with initial OSS release of PS for *nixes. It's broken from the (valid) POV of its target audience and authors want to fix in an orderly fashion. But that's not enough. People at MS are "stupid or malicious", as some commenters put it, and it should be changed ASAP the way community wants, or else.
Or else what? How many of the people arguing for immediate change are an actual and/or potential consumers of PS? How many of people thinking it's a simple change (just do it) have actually maintained large piece of software deployed by thousands of users? I bet that with the exception of Daniel who opened the bug - none.
I don't envy folks maintaining PS. I used to share an apartment with dude who can't get over the US v MS to this day and anything even tangentially related to MS (or Gates) is definitely, without any doubt evil, devious and is some sort of extortion or at the very least embrace extend extinguish strategy. No matter that US v MS was 15 years ago when he was 10. This attitude is pervasive and turbo-counterproductive in cases like this one.
Each time Microsoft releases free software, there has been discussion about whether they're really participating in a community. When Jason closes a PR, saying that it needs an RFC, and oh, by the way, you aren't allowed to start an RFC, I'm skeptical. When Jeffrey provides a work around, opens an RFC, and is generally diplomatic, I'm more hopeful.
One thing I find interesting is Frank's claim that "You have then ignored bug reports about this for years." It seems like users have a better chance of getting problems addressed on Github than the previous feedback mechanism.
Edit: after reading Daniel's blog post, which laurent123456 mentioned in another comment, this has indeed been a longstanding nuisance for curl users.
Very true! When those decisions were made PowerShell was never planned to be run on anything that ran those cmds natively. Now that they have changed the rules this should be expected as they move to a more neutral ground. I would be the 1st to call M$ on being jerks, but in this case give them a break the ship just did a 180 if you setup your furniture a certain why I guess you will have to set it up again...deal with it.
Microsoft is being hated because there's a double standard here.
If Linux tools used Microsoft utility names, someone would've been sued.
Microsoft used wget and curl `aliases` (while native versions were there) and not only the didn't get sued, they are causing problems for original authors.
Of course no hate for the engineers doing this. They are just doing their job and this is a tough compatibility issue they are facing now.
Agreed. That thread is a mixture of some useful and constructive dialogue and others just "piling on" offering problems without solutions. Those type of commenters would frustrate me to no end.
That's not exactly what they say and I agree with them that it would kind of suck if you wrote a bunch of scripts using the alias and MS broke them overnight.
Agreed. I also think people are not appreciating that even if you agree a part of your interface is bad, it's not a given that you should change it. There's a trade-off between improving your interface, and making breaking changes for your users. Evaluating that trade-off requires discussion and investigation.
It's okay: this is also an opportunity to show that they can play well with others. Done correctly they can build trust within a community that has traditionally disliked them.
Apparently a lot of people have this MS hates Open Source idea. A totally different experience you'll get when you follow the dev of VSCode, the team is just amazing, I don't know them, I don't like or hate MS but recent changes to MS has made MS embrace FOSS. Gone are the days when they pushed hard for the windows platform, now everyone runs multiple OSes, says the blog entry announcing PS.
All the comments make me incredible sad. Established projects need a valid backwards compatibility policy, this is particular true for shells and programming language to not break existing scripts.
People make mistakes and it's been agreed that introducing these aliases years ago was a mistake, albeit I think back then an understandable mistakes, given the idea to bring a shell to windows that has the power of a traditional unix shell.
Now people are loudly complaining, laughing, etc but without any constructive feedback that takes the backwards compatibility needs of a tool that is literally shipped to hundreds of million of people into account and stomping RFC approaches that are pretty similar to those in other projects (see PHP RFCs, Python PIPs, etc).
Since when did people became so hostile towards open source projects that try to do the right thing?
Powershell's "native executable" story (running things which aren't cmdlets) has never been simple or graceful [1], which means that posh scripters might call exes like curl more explicitly and avoid the alias altogether.
After months of varaible-expansion-frustration I have alnded on the form "& foo.exe par1 par2", spelling out the .exe and avoiding the alias.
And in what is starting to seem like a pattern, Microsoft makes a public move to do the Right Thing.
>jpsnover commented ... @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.
> Snover is a Technical Fellow at Microsoft & the inventor of Windows PowerShell ...
The thread goes on at length about bureaucratic requirements for the change. I guess this is what happens when you hold a bazaar inside the cathedral.
I find this comment most important in all discussion:
>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.
Kind of worrying that the inventor of PowerShell could make such a mistake. Reminds be of when rvm used an alias for "cd", which was even worse. Making up alias for popular tools such as cd, curl or wget is always a bad idea both for security and practical reasons since it breaks many tools in non-obvious ways and can be hijacked etc. It's great though that it's being fixed.
I installed PS on my ubuntu last night, it works but I don't really see the point in using it on anything but windows. Last thing I need is worry whether my scripts will run on my custom shell script as if running ubuntu didn't come with its own issues to worry about already.
> The thread goes on at length about bureaucratic requirements for the change.
I don't like the characterization of the RFC process as a bureaucracy. RFC processes are more open than a pure "bazaar". In the lack of any formal, open process to make project changes, there ends up being a hidden informal "be friends with this person to get your patch merged" process, which is far less transparent.
It's nice to see the Microsoft people being open to the dialogue but they're in a hard place here. These aliases have been in PowerShell for years, they can't be removed without breaking existing scripts.
Anyone who's used PowerShell knows that a lot of commands work differently, even `ls` and `rm`. They have different options, different text format (colors!), different output and different ways to interact with other commands. That's the very definition of PowerShell: structured interchange between commands with real objects instead of fragile strings.
wget and curl are no different. They have the names of well known UNIX commands but within PowerShell, they have their own syntax and behavior. It's not unexpected and anyone who uses bash and PowerShell regularly (I kinda do) is used to the differences between these two shells.
Devil's advocate: If you're using PowerShell on Linux you probably mean to remain compatible with a Windows workflow. PS uses other unix aliases such as ls and cat. But these all have different semantics than their namesakes. So if PS on Linux deferred to the native tools it would break compatibility with PS on Windows where those tools aren't typically available. If PS wants to remain true to its own goal of being a unified toolchain for cross-platform development, it should stick to its own implementations even if it perturbs some people who are primarily *nix developers. Because developers not working with Windows are not the primary audience of PS.
Consider that PS also aliases DOS commands such as DIR but is not compatible with the COMMAND.COM commands.
What was the thought process to add those aliases? "Yes let's implement broken aliases that supersedes actual working windows version of those utilities" ?
I'd guess they started with stuff like "ls" (where it makes a lot more sense to just execute a windows equivalent, at least in interactive use) and then somewhere someone was a bit to enthusiastic?
For stuff like this "weak" aliases which point you to the right command if it can't find an executable for it would have been a way better design. "No command with that name, you are likely looking for Invoke-WebRequest". Only slightly more work in interactive use, and safe in other cases.
Back when it was introduced, PowerShell effectively had a set of commands no one knew. To ease migration, and make things more familiar, aliases were added for many common Unix and cmd commands, e.g. both dir and ls map to Get-ChildItem.
However, having those aliases (not even limited to curl/wget or all the Unix-like aliases like ls, cp, rm, ...) is a risk since they shadow native programs that might exist. It's not as bad with dir, copy, del, since those are cmd-built-ins and thus cannot be called from anything that isn't cmd, but where already shadows where.exe.
So in general, since command resolution order places aliases before native programs, any default alias can break stuff on any machine. Which places this in pretty iffy territory. They cannot remove aliases without breaking existing scripts. This is still Microsoft we're talking about here. They don't just go around breaking stuff left and right. And they actually could never have safely introduced default aliases without a chance of breaking things.
To help bridge the gap for UNIX users who are switching over - but that being said, it's dumb since I think having the same commands that don't function the same way as the UNIX tools would confuse me more than not having them at all and having to learn a new web request command.
wget and curl aren't included with Windows. You have to go out and get them.
Powershell does come with Windows. If you don't know Powershell, having wget aliased to Invoke-WebRequest is hugely convenient, because it's the quickest way of getting stuff done; assuming your Linux knowledge is somewhat, sorta valid is a lot easier than reading a bunch of documentation or googling to see what the actual name of the command is (even though Powershell has pretty discoverable commands.)
...And I'd say that this displays a problem with the PowerShell design more than anything else. No, not that the curl and wget aliases exist: it made sense at the time, and no longer does, that's fine. The problem is that PS, unlike every other shell out there, handles structured data, which means it necessarily has to live in its own little world, with its own commandset, because even if it uses external commands, they're not going to be expecting structured data, because that's not how external commands work. So, by necessity, PowerShell is semi-monolithic, and doesn't integrate well with the rest of the system on UNIX, and integrates poorly with regular CLI apps on Windows.
This is an unavoidable problem with what PowerShell is trying to do. It doesn't make PS bad, but it causes problems.
I work on linux or mac os and a couple months ago I was trying to show an intern on windows how to use curl to make HTTP requests from the command line. Having no PS experience, I opened up PS and tried curl, saw that it was a known command but couldn't get it to work as expected since it didn't behave like curl usually does.
Was very confusing. This should definitely get fixed.
I wonder if the creators of open source software should claim trademark rights in the names of that software. "curl", "wget", "git", and "nginx", for just four examples, are probably distinctive enough in their areas of use to qualify. If the creators had trademark rights, they could then write "cease-and-desist" letters to ask others to stop using the names in confusing ways.
This wouldn't necessarily open up a trademark-troll sinkhole, because the creators of widely used software could, in their licenses, grant the use of the name to implementers of their packages.
The best way to claim trademark rights is to register the trademarks. But that's not necessary.
(Unrelated: Jeff Snover isn't a creepy guy; he's just trying to do the right thing.)
To be honest powershell has always struck me as over engineered, brimming with technological smugness, a solution in search of a problem.
Powershell fans get so excited about how their rich CLR object pipeline is so much better than a textual representation that they forget that their shell is basically an unusable theoretical exercise and still blown out of the water by "the real thing".
The fact that the designers of this platform would over-extend and try to clone "Unix utilities" (which have had windows ports for multiple decades) but completely oversimplify the purpose of these tools and fail to replicate them accurately - it's no shock to me at all.
Some of the unthinking, reflex accusations of conspiracy by Microsoft that I'm reading here are saddening and a bit disturbing.
Somebody decided to add some aliases for convenience. It turns out to have unforeseen consequences. It'll get fixed using a formal process intended to ensure that more unforeseen consequences don't follow from a breaking change.
This sort of thing happens all the time in this industry. Its not a conspiracy.
There is a way to address these things that I'm surprised they don't know about as language designers.
For these situations, making a change that breaks people's code, you have a run-time compatibility mechanism. A command line switch or environment variable can tell the language implementation "please behave like version N".
Then all changes since N which are backwards incompatible are suppressed. For instance, troublesome commands that were removed make a re-appearance.
You can then boldly fix something that is obviously wrong, while still giving any negatively affected users a way to fight any fires.
It's not a perfect solution but it placates most of the concern of the form "this is a good all-round fix, but it will break things for some unknown numbers of users".
(Users who have to be absolutely sure that their code will work the same way regardless of language interpreter and run-time updates simply have to package their work together with a specific version of those components, and have their code refer to them instead of the standard installation.)
I have to wonder how many people are really trying to run curl and wget from Windows PowerShell and running into a problem. I feel like if you're the kind of person who would do that you are also the kind who could easily configure your environment to get it the way you want. Breaking existing behavior seems like a bigger problem.
The aliases in PowerShell are a pain even for normal operations, because they don't behave like their DOS or Linux counterparts. I mean, the Get-ChildItem is aliased to dir and ls, which makes it discoverable... but it's parameters behave completely differently which just makes it confusing.
It's great that Microsoft has made PowerShell available to anyone who wants to do as they like with it and even took the trouble of packing it up for Linux and macOS, but for release, they have to care about their paying customers first, which includes some Windows admins who ignored 10 years of advice to never use aliases in a script. I'm a Skype for Business/Exchange admin who has generally followed that advice, but even I tend to use "select" instead of "Select-Object" in scripts.
This sort of thing is part of why open sourcing stuff that was developed closed and commercial isn't just a matter of tossing it up on GitHub and dropping a note here.
[+] [-] LTheobald|9 years ago|reply
[+] [-] DominikD|9 years ago|reply
And here we are with initial OSS release of PS for *nixes. It's broken from the (valid) POV of its target audience and authors want to fix in an orderly fashion. But that's not enough. People at MS are "stupid or malicious", as some commenters put it, and it should be changed ASAP the way community wants, or else.
Or else what? How many of the people arguing for immediate change are an actual and/or potential consumers of PS? How many of people thinking it's a simple change (just do it) have actually maintained large piece of software deployed by thousands of users? I bet that with the exception of Daniel who opened the bug - none.
I don't envy folks maintaining PS. I used to share an apartment with dude who can't get over the US v MS to this day and anything even tangentially related to MS (or Gates) is definitely, without any doubt evil, devious and is some sort of extortion or at the very least embrace extend extinguish strategy. No matter that US v MS was 15 years ago when he was 10. This attitude is pervasive and turbo-counterproductive in cases like this one.
[+] [-] SloopJon|9 years ago|reply
One thing I find interesting is Frank's claim that "You have then ignored bug reports about this for years." It seems like users have a better chance of getting problems addressed on Github than the previous feedback mechanism.
Edit: after reading Daniel's blog post, which laurent123456 mentioned in another comment, this has indeed been a longstanding nuisance for curl users.
[+] [-] 2close4comfort|9 years ago|reply
[+] [-] emilsedgh|9 years ago|reply
If Linux tools used Microsoft utility names, someone would've been sued.
Microsoft used wget and curl `aliases` (while native versions were there) and not only the didn't get sued, they are causing problems for original authors.
Of course no hate for the engineers doing this. They are just doing their job and this is a tough compatibility issue they are facing now.
[+] [-] kohanz|9 years ago|reply
[+] [-] superswordfish|9 years ago|reply
[+] [-] emodendroket|9 years ago|reply
[+] [-] scott_s|9 years ago|reply
[+] [-] kyberias|9 years ago|reply
[+] [-] ynniv|9 years ago|reply
[+] [-] erlehmann_|9 years ago|reply
[+] [-] wineisfine|9 years ago|reply
[+] [-] thewhitetulip|9 years ago|reply
[+] [-] hulpult|9 years ago|reply
[deleted]
[+] [-] bastardoperator|9 years ago|reply
[deleted]
[+] [-] ElijahLynn|9 years ago|reply
[+] [-] wangchow|9 years ago|reply
[+] [-] somnium_sn|9 years ago|reply
People make mistakes and it's been agreed that introducing these aliases years ago was a mistake, albeit I think back then an understandable mistakes, given the idea to bring a shell to windows that has the power of a traditional unix shell.
Now people are loudly complaining, laughing, etc but without any constructive feedback that takes the backwards compatibility needs of a tool that is literally shipped to hundreds of million of people into account and stomping RFC approaches that are pretty similar to those in other projects (see PHP RFCs, Python PIPs, etc).
Since when did people became so hostile towards open source projects that try to do the right thing?
[+] [-] nray|9 years ago|reply
After months of varaible-expansion-frustration I have alnded on the form "& foo.exe par1 par2", spelling out the .exe and avoiding the alias.
[1](https://web.archive.org/web/20110726162028/http://huddledmas...)
[+] [-] wyldfire|9 years ago|reply
>jpsnover commented ... @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.
> Snover is a Technical Fellow at Microsoft & the inventor of Windows PowerShell ...
The thread goes on at length about bureaucratic requirements for the change. I guess this is what happens when you hold a bazaar inside the cathedral.
[+] [-] akerro|9 years ago|reply
>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.
[+] [-] JeffreySnover|9 years ago|reply
PowerShell is now installed on many hundreds of millions of machines.
With great success comes great responsibility.
We can and will change things but we have to do so in a thoughtful manner.
Jeffrey Snover [MSFT]
[+] [-] patrickaljord|9 years ago|reply
I installed PS on my ubuntu last night, it works but I don't really see the point in using it on anything but windows. Last thing I need is worry whether my scripts will run on my custom shell script as if running ubuntu didn't come with its own issues to worry about already.
[+] [-] pcwalton|9 years ago|reply
I don't like the characterization of the RFC process as a bureaucracy. RFC processes are more open than a pure "bazaar". In the lack of any formal, open process to make project changes, there ends up being a hidden informal "be friends with this person to get your patch merged" process, which is far less transparent.
[+] [-] hota_mazi|9 years ago|reply
Anyone who's used PowerShell knows that a lot of commands work differently, even `ls` and `rm`. They have different options, different text format (colors!), different output and different ways to interact with other commands. That's the very definition of PowerShell: structured interchange between commands with real objects instead of fragile strings.
wget and curl are no different. They have the names of well known UNIX commands but within PowerShell, they have their own syntax and behavior. It's not unexpected and anyone who uses bash and PowerShell regularly (I kinda do) is used to the differences between these two shells.
[+] [-] laurent123456|9 years ago|reply
[+] [-] edc117|9 years ago|reply
[+] [-] yitchelle|9 years ago|reply
lzybkr wrote "We are rejecting this PR as it introduces "Unacceptable Changes", see our breaking change contract."
It is not, "let's investigate it where what the problem is and get back to you some feedback.".
[+] [-] whoopdedo|9 years ago|reply
Consider that PS also aliases DOS commands such as DIR but is not compatible with the COMMAND.COM commands.
[+] [-] chatmasta|9 years ago|reply
How have those communities dealt with the problem? Or is this a totally off base comparison?
[+] [-] mrswag|9 years ago|reply
[+] [-] detaro|9 years ago|reply
For stuff like this "weak" aliases which point you to the right command if it can't find an executable for it would have been a way better design. "No command with that name, you are likely looking for Invoke-WebRequest". Only slightly more work in interactive use, and safe in other cases.
[+] [-] ygra|9 years ago|reply
However, having those aliases (not even limited to curl/wget or all the Unix-like aliases like ls, cp, rm, ...) is a risk since they shadow native programs that might exist. It's not as bad with dir, copy, del, since those are cmd-built-ins and thus cannot be called from anything that isn't cmd, but where already shadows where.exe.
So in general, since command resolution order places aliases before native programs, any default alias can break stuff on any machine. Which places this in pretty iffy territory. They cannot remove aliases without breaking existing scripts. This is still Microsoft we're talking about here. They don't just go around breaking stuff left and right. And they actually could never have safely introduced default aliases without a chance of breaking things.
[+] [-] rohan32|9 years ago|reply
[+] [-] Amezarak|9 years ago|reply
Powershell does come with Windows. If you don't know Powershell, having wget aliased to Invoke-WebRequest is hugely convenient, because it's the quickest way of getting stuff done; assuming your Linux knowledge is somewhat, sorta valid is a lot easier than reading a bunch of documentation or googling to see what the actual name of the command is (even though Powershell has pretty discoverable commands.)
[+] [-] rasz_pl|9 years ago|reply
[+] [-] mcguire|9 years ago|reply
...
// Porting note: #if !UNIX is used to disable alises for cmdlets which conflict with Linux / OS X
#if !UNIX
... ...[+] [-] qwertyuiop924|9 years ago|reply
This is an unavoidable problem with what PowerShell is trying to do. It doesn't make PS bad, but it causes problems.
[+] [-] tps5|9 years ago|reply
I work on linux or mac os and a couple months ago I was trying to show an intern on windows how to use curl to make HTTP requests from the command line. Having no PS experience, I opened up PS and tried curl, saw that it was a known command but couldn't get it to work as expected since it didn't behave like curl usually does.
Was very confusing. This should definitely get fixed.
[+] [-] OliverJones|9 years ago|reply
This wouldn't necessarily open up a trademark-troll sinkhole, because the creators of widely used software could, in their licenses, grant the use of the name to implementers of their packages.
The best way to claim trademark rights is to register the trademarks. But that's not necessary.
(Unrelated: Jeff Snover isn't a creepy guy; he's just trying to do the right thing.)
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] asveikau|9 years ago|reply
Powershell fans get so excited about how their rich CLR object pipeline is so much better than a textual representation that they forget that their shell is basically an unusable theoretical exercise and still blown out of the water by "the real thing".
The fact that the designers of this platform would over-extend and try to clone "Unix utilities" (which have had windows ports for multiple decades) but completely oversimplify the purpose of these tools and fail to replicate them accurately - it's no shock to me at all.
[+] [-] jdright|9 years ago|reply
[+] [-] andyjohnson0|9 years ago|reply
Somebody decided to add some aliases for convenience. It turns out to have unforeseen consequences. It'll get fixed using a formal process intended to ensure that more unforeseen consequences don't follow from a breaking change.
This sort of thing happens all the time in this industry. Its not a conspiracy.
[+] [-] kazinator|9 years ago|reply
For these situations, making a change that breaks people's code, you have a run-time compatibility mechanism. A command line switch or environment variable can tell the language implementation "please behave like version N".
Then all changes since N which are backwards incompatible are suppressed. For instance, troublesome commands that were removed make a re-appearance.
You can then boldly fix something that is obviously wrong, while still giving any negatively affected users a way to fight any fires.
It's not a perfect solution but it placates most of the concern of the form "this is a good all-round fix, but it will break things for some unknown numbers of users".
(Users who have to be absolutely sure that their code will work the same way regardless of language interpreter and run-time updates simply have to package their work together with a specific version of those components, and have their code refer to them instead of the standard installation.)
[+] [-] emodendroket|9 years ago|reply
[+] [-] mcguire|9 years ago|reply
"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."
[+] [-] Pxtl|9 years ago|reply
[+] [-] MandieD|9 years ago|reply
This sort of thing is part of why open sourcing stuff that was developed closed and commercial isn't just a matter of tossing it up on GitHub and dropping a note here.