Curl author asks Microsoft to remove 'curl' and 'wget' aliases from PowerShell

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.

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.

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.

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

Microsoft needs to be patient and understanding of this mistrust, given the weight of history behind them.

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.

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

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.

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]

All open source projects (on github and everywhere else) that require a contributor agreement do the same thing (e.g. Android). They usually have bots that auto close pull requests when the person hasn't signed the agreement first.

It's an unfortunate but necessary requirement for some projects. There's no malice, just bureaucracy.

Jeffrey Snover [MSFT]

You don't think any of the particularly spazzy responders on that github thread are really Microsoft customers, do you?

As long as the OSX version of sed conforms to the standard there is no problem if it is incompatible in some areas with the GNU version used on Linux.

Also, the version of sed on OSX is around 11 years old, which helps contribute to its differences.

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.

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.

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

(This is also completely ignoring the fact that you can still call any executable; you'll just receive a bunch of strings back. The only failing here is that PowerShell doesn't have the developed string-manipulation tools like sed, awk, etc. because working with text is typically unnecessary.)

The problem is at the interface between these two modes of operation (and it'd be just as bad with a third mode, e.g. S-expressions or something else).

Honestly, it'd probably better for PowerShell to only deal with PowerShell commands, and Unix commands to only deal with Unix commands, with a well-defined interface between these two very different ecosystems.

You can be an entirely good person and do "embrace, extend". You're probably not the one making the decisions to extinguish.

It is harm from a historically bad actor.

So it's not accepted with enthusiastic gratitude.

And there's no reason why it should be.

That's not a fix. If you tell people running existing code that they need to pass a new parameter to maintain the existing behavior, you've broken them. This is no better than just telling them to update their scripts to call "Invoke-WebRequest" instead of "curl". For the record, powershell already supports this. You can request a specific version of powershell. Most of the time people don't use this functionality, though.

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

It's actually not a good all-around fix. It might be the best fix for this situation, but breaking an unknown number of users' scripts of unknown importance is still a pretty bad fix. Some guy's payroll processing will break because of this. Some startup's web scraping logic will break. Lots of stuff will break if they fix this.

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

So basically no expectation of backwards compatibility? That's why Chrome ships with its own copy of Windows, right?

Alternatively you can use a fully qualified path (c:/utils/curl.exe).

Technologically it is trivial to bypass the alias. But that doesn't mean the curl/wget people don't have a legit point about trademark usage and or incompatible args between the cmdlet (actually Invoke-WebRequest) and original UNIX utilities.

The profile is here (at least in Windows 10, it might be in a different location in other versions): C:\Users\username\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

    Get-ChildItem Alias:

Jeffrey Snover [MSFT]

http://www.theverge.com/2015/4/29/8515771/microsofts-edge-br...

https://daniel.haxx.se/blog/2016/08/19/removing-the-powershe...

Plus, step 3 literally makes no sense because these aliases only exist on the Windows implementation and everyone agrees they are substandard to the standard implementations.

But that won't prevent people from calling out EEE whenever Microsoft is involved.

But in the era of Linux, Google, and iOS, I don't think they have enough leverage to successfully implement the Extend. So they can forget the Extinguish.

That leaves only Embrace, which might work out best for all involved, a scenario wherein MS becomes a good neighbor in a diverse computing ecosystem.

In this case, nobody is going to keep using PowerShell on Linux or Mac if MS implements or promotes incompatible features. There is an exit available, where there wasn't on PCs in the 90s. I can go back to my plain old unix shell scripts, which have worked well for 30+ years.

To keep this project going, they are going to have to play nice and make sure it works well with everything. Or just abandon it. But they aren't going to be able to Extinguish anything, not in this day and age.

Neither. (If anything, perhaps the assumption of malice on the part of people who disagrees with you is what smells like Reddit)

The dynamic is something like this: The comment gets up-votes because nothing is easier than hating on Microsoft, and down-votes because it isn't actually insightful at all. You can squint at any action by any company in just the right way and make it look like it's part of "Embrace, Extend, Extinguish". The comment essentially boils down to "Microsoft has done bad things in the past, so they're probably still doing them" with precious little in the way of actual analysis.

First for your general question:

I think that people get tired of seeing the Embrace, Extend, Extinguish come up in every single thread about Microsoft.

It's a simple argument that seems to be overused and an easy grab for votes, or to bash Microsoft. If someone brings something new to the conversation by calling Embrace, Extend, Extinguish then I'm game for listening, but most the time it's just. Microsoft is a wolf in sheeps clothing look look they are Embracing. OH NOOOOOO. Open source? They can ALWAYS change their licenses? Runs on Linux? What are they going to do start offering free Windows 10 upgrades on Linux? Extinguish Extinguish!

Microsoft is a huge company, some departments suck and are run by unethical dicks (looking at you Windows 10). Their developer tools have taken some huge steps lately and have had huge success. Visual Studio Code is used by a lot of people who don't like or dislike Windows, some don't even use windows. I'm just kind of done with this argument.

Some comments on the OP:

This particular "Embrace, Extend, Extinguish" argument does bring something newish to the table calling this particular action one of the steps as foretold by our CS prophets on high. The OP gives a new spin and is on topic and shouldn't (imo) be down voted because it brings out healthy conversation (which is the point of reading comments on HN vs Reddit). If this were Reddit it would have been punnier.

Their minions write a lot of blub comments so that the comment count is higher than the voting count of a story which equals to flagging a news!!

Another very visible behaviour is that they very quickly push positive news out as soon as there is a negative news.

If you track HN stories about Microsoft with a third party HN tracking service, you clearly see evidence that unfavourable HN stories about MS vanish very quickly by flagging or overflowing the story with a lot of blurb comments to hide them. And on the same day another often minor but positive news surface and sits on HN frontpage for several hours - and of course flagging all comments that even try to hint the privacy issues with Win10 or anything remotely normal comment that isn't overly hyping their software/service.

Still not a cool move.

There is no trademark on 'curl' or 'wget', so there is not legal status to force anyone to remove features based on these names.

What level of name protection applies to command-line tools? For example, can the GNU project replace existing Unix tools with their own implementations which have the same executable name?

Copyright infringement would be if Microsoft had used GPL'd code (for example) in violation of its license. I don't think there's any suggestion that's the case here.

Your contention that there is a "real thing" would have tremendously negative impacts for the Linux/BSD community. Your typical Linux/BSD contains many utilities that share names and functionality with closed-source System-V utilities but are not in fact the "real thing" (in their case, for licensing purposes). Is everyone supposed to go back and purge those just because they aren't perfectly equivalent in options and functionality to the original System-V, lest someone like the SCO group go after them legally?

I don't think there's any doubt that PowerShell provides a bad clone of wget and curl, as there are many complaints about it. And as a matter of user-friendliness there should be a way to easily access the real executable if desired (I can't comment either way on if there is, I don't know PowerShell). However, I see Microsoft as just as within their rights to provide a "wget" alias as a Linux distribution is to provide a "ps" utility to their users.

They're simply there help people who might know bits of bash.

My impression is that these aliases were added so people wouldn't need to install cURL and wget on multiple machines.

> What is amusing to me about this incident is that I imagine Microsoft would argue that "Monad/Powershell" is aimed at its so-called "power users". Apparently these "power users" would not notice or would need something like this?

PowerShell was initially aimed at providing sysadmins a better tool for scripting tasks within Windows. They added aliases to help reduce the mental shift when changing technologies.

> Even if this can be explained away as a purely innocent "mistake", it still says something about the level of attention to detail.

At the time, it was intentional. The reality is when PowerShell was designed, there were no plans to free it and put it online, it was a pure Windows tool. The decision to add aliases made sense.

Now I know Invoke-WebRequest exists and I like it, so now I have two different tools to accomplish similar things.

And don't get me wrong, I actually agree that this use of the aliases is wrong and should be changed. We now have two options here, wait for MS to do it or fork the project. After all, it's open source.