
Curl author asks Microsoft to remove 'curl' and 'wget' aliases from PowerShell - laurent123456
https://github.com/PowerShell/PowerShell/pull/1901
======
LTheobald
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.

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

~~~
appleflaxen
Microsoft is a convicted monopolist in the EU. That's black and white criminal
(and immoral) behavior.

The PS team seems like it's doing its best, but you lose some degree of
presumption of goodwill when you work for a criminal entity.

Ultimately, I don't think either side is right, but I also don't think either
side is wrong.

MS made a choice not to cultivate goodwill in the OS community for years, and
they profited from it. It's reasonable for that community to make them earn it
back, and this is what it looks like (unfortunately for the individuals on the
PS group).

~~~
oxryly1
> Microsoft is a convicted monopolist in the EU.

As an aside, what was their punishment?

~~~
appleflaxen
the main sanction was having to un-bundle IE from Windows.

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

~~~
UK-AL
It's because it Microsoft, it doesn't matter what the issue is. People just
want an excuse to bash them.

~~~
plandis
To be fair one of the first comments on the issue is some guy from Microsoft
saying:

"We can't make this change without an RFC. Oh, by the way, the community
cannot create an RFC."

If I was actually interested in using powershell on Linux I too would be a
little upset they Microsoft is so unwilling to work with the community.

~~~
Aldo_MX
You are not giving the whole context:

> We can't make this change without an RFC. Oh, by the way, the community
> cannot create an RFC, WE INTEND TO OPEN THIS UP.

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

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

~~~
kyberias
How is that comment useful? No-one is denying anything. It's obvious that the
decision to implement those aliases was incorrect. It's not like Microsoft is
saying that it was correct.

It's not a question of who was right or who to blame. It's a question of how
to make the changes because there _are_ users that depend on those aliases.

~~~
emodendroket
They are also honestly pretty useful as a new user. `ls` and `dir` are more
obvious things to try than `Get-ChildItem`.

~~~
kuschku
Then maybe design new ones?

"download" aka "dl" instead of curl/wget?

"list" instead of ls/dir?

Would also make them easier googleable

~~~
Eyas
That's not the problem MS was trying to fix with the Linux aliases -- the
problem they were trying to fix was ergonomics. A lot of us are used to Linux
commands and are turned off by Windows shells when we have to learn a new set
of commands and can't use `ls`.

In fact, being able to do `ls` rather than `dir` on PowerShell was one big
reason I gave it a chance. My other Windows shell experiences have been
supremely intolerable because of that.

With curl and wget, Microsoft admits they were overeager.

~~~
kstrauser
I think the correct ergonomics would be if you saw:

    
    
      $ curl http://example.com/foo
      Fetching http://example.com/foo by emulating curl
      This command is an alias for "...".
      If you've installed a real curl command, disable this by typing...
    

so that you could still use muscle memory to type the commands you know, could
see what the actual underlying command is so you could adapt to it, and would
know how to use the Real Thing if you have it.

~~~
emodendroket
Kind of noisy, isn't it?

~~~
kstrauser
It is, but the noise is telling you how it differs from what you'd normally
expect and how to address it. I think that's an acceptable tradeoff.

~~~
emodendroket
I think it is immediately obvious from the output that it's not the same
program, without the message.

~~~
kstrauser
Really? What's the normal output? The content of the URL being fetched. If
that message was to STDERR so that curl > foo worked without alteration but
the help text still showed up on the console, I think fewer people would be
surprised.

The number of bugs about this indicates that people _are_ still being
surprised.

~~~
emodendroket
That is not the output of the PoSh command. Like most of them it outputs a
list of object properties and values:
[https://mcpmag.com/articles/2013/01/22/~/media/ECG/mcpmag/Im...](https://mcpmag.com/articles/2013/01/22/~/media/ECG/mcpmag/Images/2013/01/130121mcp_hicks01.ashx)

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

~~~
SloopJon
I'm not too familiar with PowerShell, but I wonder if they could introduce new
syntax to fix this. Add a new statement, like import, include, use, or using;
if your script includes that statement, you don't get the aliases unless you
ask for them (e.g., using LegacyAliases).

~~~
ambulancechaser
The problem with that is that it breaks existing scripts. If you have to
update old scripts, why try to maintain the legacy stuff in the first place.

~~~
SloopJon
No, it doesn't, because existing scripts don't include this new statement. You
only have to make your aliases explicit if you edit a script to use this new
namespace/module feature.

------
laurent123456
Additional info in his blog post:
[https://daniel.haxx.se/blog/2016/08/19/removing-the-
powershe...](https://daniel.haxx.se/blog/2016/08/19/removing-the-powershell-
curl-alias/)

~~~
edc117
This seems far less dramatic than the thread is making it out to be.

------
yitchelle
I think MSFT needs to try harder at their customer service. Their first
response from a human was hard rejection response.

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

~~~
emodendroket
They don't even have an obligation to consider outside PRs, let alone provide
a reason. It's rather a stretch to say people who want to change the behavior
of PowerShell are their main customers.

~~~
nkassis
Depends what main customers you are thinking off. For this product in
particular, it seems these users might be potential customers of powershell.
Each product has it's own main customers.

~~~
wolfgke
The customers who pay money.

~~~
JeffreySnover
FYI - we don't charge for PowerShell.

Jeffrey Snover [MSFT]

~~~
wolfgke
That was exactly part of my point: "main customers" are people who pay to
Microsoft, e.g. for Windows licenses.

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

------
chatmasta
This seems like a similar issue to how `sed` is implemented slightly
differently on OSX/Darwin systems and Linux systems.

How have those communities dealt with the problem? Or is this a totally off
base comparison?

~~~
blumentopf
Totally off base. BSD versus GNU conventions.

~~~
JdeBP
If you think that that does not, _similarly_ , generate long "But it breaks my
scripts!" "Your scripts were wrong." "You should have named the right shell
interpreter." "BSD commands are insane." "GNU commands are non-standard." "Are
you going to fix all of the scripts that currently rely upon this?" "But this
is the de facto standard!" "Have you forgotten about this large userbase over
there?" "I don't care what you say, as far as I am concerned this is bash." "I
don't care what you say, it's Terminal because I use a terminal to type." "It
should be tar." "It should be cpio." "Now it's pax." "What exactly _are_ the
options to the 'ps' command?" "Why did you think that you had a command named
'll'?" "No, the superuser's login shell is intentionally the same as it has
been for 30 years." "Why does _the user manual_ have a (sometimes little more
than a placeholder) note telling me to read _something else_ for the user
manual?" "We're settling on info documentation." "No, we're not." "Hey people,
I've had a bright idea of documenting everything in HTML and I'm calling it
[http://cr.yp.to/slashdoc.html](http://cr.yp.to/slashdoc.html) ." "The
_compatibility mechanism_ is _of course_ to put /usr/xpg4/bin in your PATH."
"No, that's gmake." "No, that's gawk." "Ah, actually it's mawk." "No, I think
it's nawk." "I'm the real ksh!" " _I_ am the real ksh!" "That's because it's
the -I option, not the -i option." "We've actually had a non-interactively-
usable general-purpose in-place text editor since Bill Joy wrote ex." "But ed
is the Unix standard." discussions ...

... then you have not read enough of Usenet, WWW discussion fora, mailing
lists, and others. (-:

------
mrswag
What was the thought process to add those aliases? "Yes let's implement broken
aliases that supersedes _actual working windows version_ of those utilities" ?

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

~~~
tobias3
They could have just bundled cURL with PowerShell/Windows like macOS does. But
NIH, I guess?

~~~
UnoriginalGuy
Powershell is an object world, cURL is a string utility. You wouldn't want to
bundle it, you want people to use Invoke-WebRequest (current cURL alias).

The alis just needs to be removed. They should replace it with a manpage that
suggests cmdlets for popular UNIX commands if those commands aren't found
(e.g. if curl returns "not found" it tacks on, "You could try XYZ cmdlet
instead").

~~~
jodrellblank
_Powershell is an object world, cURL is a string utility. You wouldn 't want
to bundle it, you want people to use Invoke-WebRequest (current cURL alias)._

Specifically, for non PS users reading, Invoke-WebRequest returns n object
with the page content parsed and a live DOM to work with, as well as the
request headers and the raw data. It's very convenient.

Including curl.exe would not do that.

------
mcguire
Has anyone looked at the big list o' Powershell aliases? This is from the
section containing wget and curl:

...

// Porting note: #if !UNIX is used to disable alises for cmdlets which
conflict with Linux / OS X

#if !UNIX

    
    
                        // ac is a native command on OS X
    
                        new SessionStateAliasEntry("ac",
                            "Add-Content",     "", ScopedItemOptions.ReadOnly | ScopedItemOptions.AllScope),
    

...

    
    
                        new SessionStateAliasEntry("cpp",
                            "Copy-ItemProperty",   "", ScopedItemOptions.ReadOnly | ScopedItemOptions.AllScope),
    
                        new SessionStateAliasEntry("diff",
                            "Compare-Object",  "", ScopedItemOptions.ReadOnly | ScopedItemOptions.AllScope),
                

...

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

~~~
jdmichal
Your comment ignores the major integration that PowerShell does provide: .NET.
PowerShell can invoke any .NET code and work with the objects returned
therefrom. Yes, it has terrible integration with text-based tools, because
it's not a text-based shell. It has great integration with the .NET object-
based environment, because it's a .NET object-based shell.

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

~~~
jodrellblank
_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.)_

What kind of tools does it not have? It has all the .Net style string methods
(split, trim, and so on), all the .Net regex methods, built in arrays and
hashtables, looping over lines of text shortcuts.

It's pretty trivial to do small scale ad-hoc text parsing, cut lines by a
character, take element 4, cast to 'datetime' and add +4 days to it, handwave
a counter into existance and +1 it, match a regex and do some replacement or
group some fields.

It doesn't go as far as sed "in-place text replace" or awk records, but saying
it "doesn't have developed string-manipulation like sed" is like saying that
of Python. And if you were writing Python you wouldn't need to call out to awk
because you'd just use Python string processing and basic data structures for
what you were doing, right?

~~~
jdmichal
I meant exactly that "it doesn't go as far as sed... or awk...". PowerShell
has what I would term the primitives of string manipulation, inherited from
.NET -- substring, trim, regex replace, etc. But it does not have the advanced
methodologies that sed and awk provide. Especially in regards to editing,
since PowerShell also inherits .NET's immutable strings.

~~~
qwertyuiop924
This. AWK is the best tool for record DSV record manipulation I've ever used.
Some would say that it has since been surpassed by other scripting languages,
but I disagree. It's fast to learn, and is incredibly good at what it does,
with a very simple and elegant design. Simple AWK scripts can read like
descriptions of what you want done. Like this script that prints all users in
/etc/passwd that have home directories in /home:

    
    
      BEGIN{$FS=':'}
      $6~/^\/home.*/{print}

------
tps5
This is funny.

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

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

~~~
jdright
Perfectly said, can't agree more.

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

~~~
traverseda
If you're referring to my post, I don't think "conspiracy" is the right word.
The "extend" part of "embrace, extend, extinguish" is just due to them having
a somewhat insular culture that doesn't make use of upstream.

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

~~~
andyjohnson0
I only see one post by you on this topic, and thats the one I'm replying to.
So no, I wasn't referring to you.

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

~~~
dpark
> _A command line switch or environment variable can tell the language
> implementation "please behave like version N"._

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?

~~~
kazinator
> _If you tell people running existing code that they need to pass a new
> parameter_

So, make it an old parameter by having this from the beginning in your
language.

Once the parameter is several years old, it's no longer a new parameter.

Users can use it proactively, before something breaks. It can be a recommended
practice for deploying code.

> _This is no better than just telling them to update their scripts to call
> "Invoke-WebRequest" instead of "curl". _

It is substantially better than asking people to change source code.

Users can still change their scripts to call Invoke-WebRequests (and should!);
just in the short term, they just adjust some version mechanism.

> _That 's why Chrome ships with its own copy of Windows, right?_

Windows has versioning mechanisms in some of its API's, by which it can tell
that a program is calling it that was compiled for an old version.

Speaking of browsers, web pages declare what version of HTML they are in with
<!DOCTYPE ...>. If your page begins with <html>, you can't expect it to render
the same way everywhere.

Deploying applications in containers with copies of operating systems is not
unheard of these days.

> _So basically no expectation of backwards compatibility?_

Backward compatibility is the normal _modus operandi_. This type of mechanism
is just for "oh shit" situations: there is no way we can fix this thing while
remaining backward compatible. Any newly introduced use of the version
emulation is treated with great regret.

~~~
dpark
> _So, make it an old parameter by having this from the beginning in your
> language._

It's already part of PowerShell. You can request a specific version when you
run PowerShell.

[https://msdn.microsoft.com/en-
us/powershell/scripting/core-p...](https://msdn.microsoft.com/en-
us/powershell/scripting/core-powershell/console/powershell.exe-command-line-
help#version-windows-powershell-version)

> _Users can use it proactively, before something breaks. It can be a
> recommended practice for deploying code._

I'm sure it is recommended practice. That's irrelevant if people aren't
following that best practice. And they generally aren't, because it adds
friction to development.

The "go back in time and do it right from the beginning" fix isn't feasible
due to the lack of reliable time machines.

> _It is substantially better than asking people to change source code._

It's really not. If the workaround avoided compilation, this would be lower
cost. But the cost to make a small change to a script and the cost to change
the way the script is invoked are pretty much the same.

> _Windows has versioning mechanisms in some of its API 's, by which it can
> tell that a program is calling it that was compiled for an old version._

No. Windows is just super-serious about backwards compatibility. Some APIs are
versioned. Most are not. Microsoft just bends over backwards to keep stuff
running (to the point of emulating bugs that programs relied on).

> _Speaking of browsers, web pages declare what version of HTML they are in
> with <!DOCTYPE ...>. If your page begins with <html>, you can't expect it to
> render the same way everywhere._

Also no. HTML5 did away with the versioned doctype crap because it wasn't
actually useful. It's just "<!DOCTYPE html>" now, because that's what you need
to get browsers to render your site in a standards-compliant way.

> _Backward compatibility is the normal modus operandi. This type of mechanism
> is just for "oh shit" situations: there is no way we can fix this thing
> while remaining backward compatible. Any newly introduced use of the version
> emulation is treated with great regret._

This type of mechanism 1) already exists for powershell, and 2) doesn't really
help much here. I'm sure if they take this breaking change, they'll advise
impacted people to use this workaround if they cannot for some reason fix
their scripts. But this is not a "fix".

Disclosure: MSFT employee, but not on PowerShell or Windows

~~~
kazinator
I never called this a "fix". I used "fix" in reference to whatever backward
incompatible change was being made to make this workaround necessary. (For
whatever reasons, it is considered a fix that is desirable; and so the
question is then now to mitigate the impact.)

Of course the fix for any behavioral regression is to make it go away without
the user having to do anything (other than apply the fix).

The versioning request mechanism has to be supported via an environment
variable also, because if a user has a tree of scripts calling each other, it
may not be feasible to insert this extra argument into all those calls.

> _But the cost to make a small change to a script and the cost to change the
> way the script is invoked are pretty much the same._

That is true, but the cost to make hundreds of changes to a script versus one
command line parameter isn't the same. A change which breaks backward
compatibility could affect some programs in many places.

There is also the cost of finding _that_ there is a problem, and _what_ that
problem is: where is it breaking and what changes need to be made. All while
ensuring that those changes work for the older versions of the interpreter
too, not just in the upgraded environment.

Say I have some big, 10000 line script. I update to a new interpreter, and the
script doesn't work. First thing I will try is the compat option to emulate
the previous version. If it works, then there is my workaround; for the time
being, I don't have to _care_ why, or whether forty places in the script are
affected or only three. The thing has a way of continuing to work (for a good,
long time) so I have plenty of time to investigate it. I can treat it as a
low-priority issue and give it as a background task to a co-op student instead
of as an urgent blocking issue.

> _HTML5 did away with the versioned doctype crap because it wasn 't actually
> useful. It's just "<!DOCTYPE html>" now,_

I.e. HTML5 just shortened the spelling of the utterance that you need to
indicate that "this page is HTML5". If your page is HTML4, you need the older,
more verbose utterance.

~~~
dpark
> _I never called this a "fix"._

You called it a solution. You called it a way to address the issue. Nitpicking
use of the specific word "fix" is pointless, when you were clearly proposing
this as a fix.

> _That is true, but the cost to make hundreds of changes to a script versus
> one command line parameter isn 't the same. A change which breaks backward
> compatibility could affect some programs in many places._

You're right. The cost to hack it with a specific version is _higher_. You
either have to set a system-wide environment variable (which someone will
forget about and ship a break because locally they were using a newer version)
or you have to inject it at each point a relevant script could run. Or you
could do a find/replace for the problematic alias and be done.

> _There is also the cost of finding that there is a problem, and what that
> problem is: where is it breaking and what changes need to be made. All while
> ensuring that those changes work for the older versions of the interpreter
> too, not just in the upgraded environment._

It's literally a grep/findstr. I don't know why you're acting like it's hard
to find uses of the tokens "curl" and "wget" in ps1 files.

> _Say I have some big, 10000 line script. I update to a new interpreter, and
> the script doesn 't work. First thing I will try is the compat option to
> emulate the previous version. If it works, then there is my workaround; for
> the time being, I don't have to care why, or whether forty places in the
> script are affected or only three. The thing has a way of continuing to work
> (for a good, long time) so I have plenty of time to investigate it. I can
> treat it as a low-priority issue and give it as a background task to a co-op
> student instead of as an urgent blocking issue._

What are you talking about? The whole reason to maintain backwards
compatibility is so you don't end up in this situation. You can use the
version switch if you need to, but in general if you need to in production it
means someone screwed up.

In the scenario you described, there's a 95% change you'll never take the
version switch off once it's in place (because it's "low priority"), so you'll
have this hanging over your head until something breaks and it becomes
critical to upgrade, at which point you'll be frantically trying to fix the
problem and cursing Microsoft for not maintaining backwards compatibility.

> _I.e. HTML5 just shortened the spelling of the utterance that you need to
> indicate that "this page is HTML5". If your page is HTML4, you need the
> older, more verbose utterance._

Not exactly. If you slap the "HTML5 doctype" on an HTML4 page, it's expected
to work. Because again, that abbreviated doctype is all you actually need to
get a browser to use standards-compliant mode. But also, this is the doctype
going forward. So far as I understand, there is no plan for HTML6/7/whatever
to change this. Because backwards compatibility is greatly preferred over
trying to force a specific version.

~~~
kazinator
If I have a problem with Firefox and switch to Chrome, that addresses my
problem and is a solution; yet it isn't a fix! When I use words like
"address", I'm specifically being weasely, avoiding the word "fix". :)

> _The whole reason to maintain backwards compatibility is so you don 't end
> up in this situation._

That's the ideal, which ignores the negative aspects of absolute backward
compatibility. Very good backward compatibility most of the time is all round
better than perfect, absolute backward compatibility.

If you want perfect backward compatibility _and_ an excellent design
everywhere, then you have to make only perfect design decisions in everything
right from the start.

Dennis Ritchie regretted not fixing the precedence of the & operator in C.
It's strangely low because at one time there had been no logical && operator
and & was used in its place. He wanted to fix it, but, alas, the story goes,
they already had several hundred kilobytes of C code written across three
machine installations. The result: a piece of technical debt spread to
immeasurable numbers of lines of C written since, world over.

> _I don 't know why you're acting like it's hard to find uses of the tokens
> "curl" and "wget" in ps1 files._

Simply because I'm thinking of the whole class of possible backward-
incompatible changes in a language or library, not all of which can be
necessarily found this way. For the ones which can be found by looking for
specific identifiers, you need reliable release notes to tell you what they
are.

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

~~~
UnoriginalGuy
You can bypass this problem by appending ".exe" to the end of your command
anyway, as in, "curl.exe" instead of "curl" fixes the alias problem and allows
native curl to run.

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.

~~~
emodendroket
Yeah, but the aliases are mostly meant for an interactive scenario where it
has real value to be able to just try typing in a command you know and then
you can actually look at the docs to understand the details, rather than
having to Google "PowerShell equivalent to wget" or whatever.

------
mcguire
I think I may quote this when the periodic "text input/output is stupid"
threads come up.

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

~~~
emodendroket
What that actually means is that if you change a command so that it runs a
totally different program the script would break, which is equally true in a
stringly-typed world.

~~~
Jtsummers
Though in the stringly-typed world, it's when the format changes from:

    
    
      A B C

to:

    
    
      A B D C

Or some other such thing. Your string processing code (perl, sed, sort, uniq,
etc.) expects certain things that have now changed because <reasons> (which
may be totally reasonable or unreasonable).

~~~
emodendroket
Yes, but if it's a totally different program there's no real reason to expect
the output to be even slightly similar.

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

~~~
hibbelig
Maybe `cd` is a shell builtin, so I expect its behavior to change when I
change shells. So it's not a problem to have `cd` behave slightly differently
in bash, zsh, fish, PowerShell.

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

------
protomyth
Is there a list of all the commands they alias?

What is the filename of the profile jpsnover is referring to with the work
around of adding:

    
    
      Remove-Item Alias:Curl
      Remove-Item Alias:WGet

~~~
yakk0
get-alias will list all the aliases on your system.

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

~~~
Senji
$profile already points to it.

------
spdustin
I'll leave the MS politics out of my comment, and just summarize my suggestion
[0] to handle this sort of thing. A module that has exported module members
allowing you to opt-in to future breaking changes _now_ could be added to
PowerShell, similar to how Python has _from future import [whatever]_. So you
could remove curl and wget aliases by adding _Import-Module
Future.RemoveAliases.Net.Http_ to your profile, or even opt-in to all future
breaking changes by adding _Import-Module Future_ to your profile. I wonder
what Daniel would think of that idea.

[0]:
[https://github.com/PowerShell/PowerShell/pull/1901#issuecomm...](https://github.com/PowerShell/PowerShell/pull/1901#issuecomment-241100571)

------
rootlocus
One of the arguments I saw from the Microsoft guys was that it's consistent
with other "aliases" PowerShell has (like ps and ls).

Reminds me of a demotivational poster we have at the office:

[https://www.google.ro/search?q=demotivational+poster+consist...](https://www.google.ro/search?q=demotivational+poster+consistency&biw=1920&bih=995&tbm=isch&imgil=wlsu-
mX1EFKYBM%253A%253BODUUUUR5Vh0_AM%253Bhttp%25253A%25252F%25252Fdespair.com%25252Fproducts%25252Fconsistency&source=iu&pf=m&fir=wlsu-
mX1EFKYBM%253A%252CODUUUUR5Vh0_AM%252C_&usg=__L3-zFKPTsX5ICIEwWgnAO83bh2g%3D&ved=0ahUKEwjohNvL_s3OAhWKvBoKHZ6cAwcQyjcIJw&ei=0D-3V-jcDIr5ap65jjg#imgrc=wlsu-
mX1EFKYBM%3A)

It reads: "Consistency: Only a virtue if you're not a screwup".

------
Gaelan
I think that *nix commands can be split into roughly two groups: ones that
feel like generic "actions" and have multiple implementations (ls, cd, cat),
and ones that refer to specific pieces of software (curl, emacs). The first
category should be aliased to the PS equivalents, while the second should be
left as-is.

With commands like ls, I'd prefer to have my muscle memory get me the first-
class Powershell experience (which means a structured list of files, not a
string containing ls's output) instead of attempting to act exactly like ls
acts in bash. If I didn't want to use Powershell's features (which /bin/ls
does not support) I wouldn't use Powershell.

------
ilaksh
PowerShell is really cool but its not a traditional shell at all. Totally
different model. Also, Windows is not Linux. Stating the obvious but people
seem to be doing a mashup without quite noticing the level of difference.

Its not an open source organization. If it was, they would have the discussion
there rather than just closing it and talking about an RFC.

I think they should add an install option rather than nust defaulting to those
aliases.

MS does need to continue making money. No matter how much people pretend
otherwise, that means they have a conflict of interest with open source and
Linux. And the web platform (still). And with so many billions at stake, yes
their actions reflect this conflict.

------
krupan
There is so much weight of history for Microsoft to overcome if they want to
now be accepted and trusted by the open source community. I'm willing to
believe that at least parts of the company are sincere and serious about
achieving that, but they need to have a thick skin and be understanding when
people don't immediately trust them right off the bat.

Many long years of name calling and Embrace and Extend (which this particular
issue feels a lot like) are going to take some time, patience, and long
suffering on their part to counteract.

------
kzisme
For the curious here is the authors blog post about it:
[https://daniel.haxx.se/blog/2016/08/19/removing-the-
powershe...](https://daniel.haxx.se/blog/2016/08/19/removing-the-powershell-
curl-alias/)

------
senthilnayagam
Dear Microsoft bundle curl and wget in the next patch / major release. Your
Historical blunder can be forgiven and you can make new friends in open source

------
moomin
You think that's bad. They alias ls as well...

~~~
UK-AL
ls is a standard on many different shells, with different implementations.

~~~
hibbelig
Are there shells where `ls` is a built-in?

I just replied to another comment where I wanted to say that I don't mind that
the PowerShell version is different because `ls` is a built-in. But then I
discovered it's not. So I just used `cd` in that comment...

~~~
JdeBP
Read about the C shell's "ls-F" built-in command.

~~~
moomin
Don't get me started on the awfulness of csh...

------
viggity
Isn't there a third way? make the PS versions of curl and wget adhere exactly
to the original interface/specs?

~~~
JeffreySnover
Yes but I think the better solution is to fix the alias problem and then work
with Daniel to make it super simple for people on Windows to get his
latest/greatest bits. I've reached out to him to start that conversation.

Jeffrey Snover [MSFT]

------
pweissbrod
I wonder how many venomous comments in the PR were authored by people even
remotely affected by the issue. I wager the answer is 0.

------
erlehmann_
To me this looks like a twisted version of step two of the “Embrace, extend
and extinguish” strategy – creating interoperability problems:
[https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

To recap:

1\. Embrace: Development of software substantially compatible with a competing
product, or implementing a public standard.

2\. Extend: Addition and promotion of features not supported by the competing
product or part of the standard, creating interoperability problems for
customers who try to use the 'simple' standard.

3\. Extinguish: When extensions become a de facto standard because of their
dominant market share, they marginalize competitors that do not or cannot
support the new extensions.

~~~
wyldfire
I think Hanlon's razor applies better here than embrace-extend-extinguish.

~~~
omginternets
Hanlon's razor applies when there is no evidence pointing towards malevolence.
There is ample evidence pointing to EEE in the case of Microsoft.

~~~
voltagex_
>There is ample evidence pointing to EEE in the case of Microsoft.

Forever?

~~~
omginternets
Let's flip this around. Are you sure you want to argue that past behavior
can't inform us (to some degree) on future behavior?

------
douche
I guess Powershell is going to have to take out all of it's useful aliases...

Bye ls, rm, cp, etc

~~~
Senji
They should put a flag that's something like $clobber_posix with default state
of off.

------
frik
429 points by laurent123456 4 hours ago | 289 comments

And already pushed off the frontpage, yet stories with 16 votes are now on the
frontpage.

------
erlehmann_
Offtopic: What I find interesting about this discussion is that comments
regarding “Embrace, Extend, Extinguish” and Microsoft's past misbehaviour got
upvotes first, then suddenly many downvotes at once. I have seen this earlier
on HN with other controversial topics and I do not know what it implies.

Is this voting brigading / shilling or just normal behaviour of groups trying
to suppress dissenting voices?

Also, is this part of why semi-noobs think that HN is turning into reddit?

~~~
sctb
We detached this subthread from
[https://news.ycombinator.com/item?id=12319735](https://news.ycombinator.com/item?id=12319735)
and marked it off-topic.

~~~
erlehmann_
I think I understand what detaching means, but what effect does marking a
thread off-topic have?

------
asah
IANAL but this seems like a pretty clear cut case of copyright infringement,
I.e. a situation where an ordinary person might be confused into thinking that
PowerShell curl/wget provides the real thing, but does not.

Although I suppose that PowerShell could fall under "parody."

EDIT: this was sarcasm.

~~~
ihuman
Are curl and wget copyrighted? I thought they were free software under a
copyleft-style license.

~~~
Kihashi
That doesn't mean that they aren't copyrighted. It just means that you can
freely use them under the terms of their copyright license. If the code for
them were not copyrighted (usually referred to as Public Domain), then you
could do whatever you wanted with them-- things like making derivative works
and using a commercial license.

~~~
Lennie
Let's be very clear here.

This is not true:

No copyright notice == Public Domain.

Everything You make gets Your copyright by default. This means the default is:
nobody can use what You make.

You can put other copyright terms on your works by adding a copyright notice.

You can put something in the Public Domain by adding a notice to your work.

Things can also become Public Domain automatically after a certain amount of
time. But that time has been extended several times in the US to something
unreasonable: like 75 years after the death of the author. You can thank
Disney/Mickey Mouse for that.

------
Graham67
Create a list of tests. Report how many of the tests pass/fail.

~~~
emodendroket
I don't think you understand the problem.

------
mydpy
This is kinda awesome. This repo has been public for less than 24 hours and
Daniel Stenberg (@bagder) already put in a PR to remove wget and curl? That's
amazing. What a Swede.

------
micro_softy
One is always left with the impression Microsoft thinks their users are
ignorant, for lack of a better word.

Of course, along with all those users who Microsoft treats as ignorant, again
for lack of a better word, there are some very sharp people who use Windows --
who will perhaps take offense at any criticism of Microsoft -- no offence
intended! (I am just not smart enough to feel confident with Windows myself --
too complicated.)

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?

Intentionally or not, Microsoft is targeting beginners, not "power users" \--
tactics like this leverage the popularity of the curl and wget programs and at
the same time prevent beginners from learning how to use those programs, not
to mention the long history behind them.

Disclaimer: I prefer nc, socat and tnftp myself; I have no bias in favor of
curl or wget.

~~~
Delmania
> One is always left with the impression Microsoft thinks their users are
> ignorant, for lack of a better word.

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.

~~~
micro_softy
Yes or no question: Is it deemed too difficult for a user to create their own
aliases, based on their own needs?

Why should anyone have to make a "mental shift"? The answer is not because
UNIX is incompatible with other systems. The answer is more likely because
Microsoft Windows is a proprietary commercial product; its sales and marketing
staff have traditonally sought to discredit UNIX. Having followed Windows from
3.11 onwards I would argue that it is "different" and incompatible by design.
The "mental shift" is intentional and strategic, but not at all necessary.

Why were there no plans to make PowerShell free and open source and publicly
available initially? That's a rhetorical question of sorts.

UNIX as the OS that generally "runs the internet" has become better known and
more popular in recent years as a result of several factors. That's why MS has
to make the moves they're making. keywords: "has to"

~~~
Delmania
>Yes or no question: Is it deemed too difficult for a user to create their own
aliases, based on their own needs?

Are you intentionally trying to be difficult? The answer is of course not,
considering there is the New-CmdLet alias. These aliases exist purely as
convenience factor.

> Why should anyone have to make that "mental shift"? The answer is not
> because UNIX is incompatible with other systems. The answer is because
> Microsoft Windows is a proprietary commercial product and its sales and
> marketing staff have always sought to discredit UNIX. Having followed
> Windows from its inception I would argue that it is "different" by design.
> The "mental shift" is intentional, but not at all necessary.

You followed Window's inception, and this is the best argument you can come up
with? A not to subtle attempt to discredit the company? Your answer ignores
the fact that Windows was built on top of a DOS derivative and the scripting
language for Windows for many years was batch. It was different because it
wasn't based on UNIX at the time because Linux was still in development.

>Why were there no plans to make it free and open source and publicly
available initially? That's a rhetorical question of sorts.

I'd imagine because it was aimed at people who were managing Windows servers.
Considering Linux has a robust set of tools to do that, there would have been
no reason to do that.

>As I see it, UNIX as the OS that generally "runs the internet" has become
better known and more popular in recent years as a result of several factors.
That's why MS has to make the moves they're making. keywords: "has to"

I don't think anyone on this thread would deny that. The question is how is
that remotely relevant? Companies have to change strategies in order to
respond to the markets they operate in. Companies survive on profits and
revenue. It makes sense their actions would be guided by those. Why is this a
difficult concept for people to understand?

~~~
micro_softy
OK, if you meant going from DOS batch to UNIX sh scripts, i.e., from one
scripting language to another, as the "mental shift", then that's fair.

But using an alias for a program that may be called by a script is not going
to address that.

A user can just as easily call curl.exe using BAT, WSH, etc., or PS.

As for DOS, keep in mind MS did not even write the software that became MS-
DOS; they bought it.

Many believe it was a copy of the work of Gary Kildall whose CP/M was
undisputedly more original and superior in quality to anything else for the
"PC".

Using their usual tactics (remember "vaporware"?), MS extinguished Kildall's
DR-DOS, and put his company out of business.

Later they paid a $150 million settlement for this move.

What is difficult to understand is why MS cannot make money without copying
and interfering with other companies.

What's wrong with their "original" work? Can't they sell that?

Will they use the same tactics against open source projects that write
software for UNIX? Maybe that is what concerns people here.

Also difficult to understand why they must _force_ users to "upgrade" and OS
that already works? Profits and revenues. Right. Rah rah Redmond.

If this behavior is what they must do in order to derive "profits and
revenues" then why would you be confounded by people who would question it?

I'm all for winning in business, profits and revenues, but truthfully I am
here because I like using, reading and trying to write software that is better
than average.

Microsoft offers nothing in this regard.

------
mitm2mitm
Am I crazy or is Microsoft announcing new open source or dev friendly stuff
everytime there's a PR bomb here on HN?

18/08/2016
[https://news.ycombinator.com/item?id=12305598](https://news.ycombinator.com/item?id=12305598)
With Windows 10, Microsoft Disregards User Choice and Privacy (eff.org)

A day later they announce Power Shell is open source.

I remember a few months ago they blasted HN's frontpage with news after a few
discussions about telemetry and EEE (first wave of Windows 10/UWP showing its
true colors).

I don't care enough to do a reddit-esque investigation on HN stories. I just
find it funny, that's all.

~~~
frik
You are definitely not crazy nor alone with watching these PR tactics. I
dislike that so many MSFT employees/puppets/bots/fanboys frequent HN since
Build conference 2015. I would prefer the HN of pre-Spring-2015 with news
about venture capitalists, startups and software that matters to startups -
and not corporate PR about software that doesn't make sense for startups. See
how MySpace lost, look what software stack they used and how it burned through
cash because of very expensive license fees, compare it to Facebook. Everyone
who got burned by the Seattle guys once usually learn and avoid getting burned
again.

