

PowerShell Specification licensed under the Community Promise - brudgers
http://blogs.msdn.com/b/powershell/archive/2011/04/16/powershell-language-now-licensed-under-the-community-promise.aspx

======
thwarted
_This means that now anyone can implement PowerShell on any platform they want
to. We know some of our most passionate customers sometimes work on platforms
that can’t run PowerShell today, so when writing this specification, we wrote
it in a platform neutral manner._

 _We hope to see implementations on all of your favorite platforms. This would
benefit the industry, our partners, and our customers. We told you that you
should learn PowerShell and we would do everything we could to make it the
best investment you ever made. Specifying the language and enabling the
community to implement it is yet another step in that direction._

It's interesting how many open source projects are expected to, and do, port
their projects to Windows, but Microsoft expects the community to do the work
of porting their projects to other platforms. Now obviously, Microsoft isn't
usually the one doing the expecting, but Microsoft has a lot more resources
than any random person doing a port in their freetime.

I remember when Apache wasn't available for Windows; and I remember when
Microsoft "let" the Mono team write their Silverlight port.

This is all just marketing. They can say they are open and working with the
community, but they are offering something empty: anyone who wants to use
Powershell, or has experienced its value, is already working on Windows and
most likely isn't interested in working on any other platform. And thus there
is no one (or close to no one) who is both interested in doing and qualified
to do a port. And I think Microsoft has shown their track record of working
with the community only to continuously leave community products at least one
step behind the moving target that is their "standard", often defined as
whatever the latest from Microsoft offers. Everyone else's ports are seen a
lesser because they are behind the "official" release.

Now, obviously, different implementations are good for the standard and market
overall, and only serve to strengthen it from a diversity standpoint. But it's
interesting that Microsoft is actively encouraging forks of their projects
when they've, in the past, cited forks as a deficiency of open source.

------
y0ghur7_xxx
The language specification is only in docx[1].

Microsoft, just put an HTML page with the spec online. There is no need for a
docx file for a language specification.

[1][http://www.microsoft.com/downloads/en/details.aspx?FamilyID=...](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=509b77d0-5e5f-4194-a2d0-61648abfd093)

~~~
lloeki
You're lucky it's not in the Microsoft PDF killer format: XPS!

Still, I always wondered why they keep publishing stuff like this in a
"working" format (doc, odt...) instead of a "distribution" format (ps, pdf...)
.

------
jkahn
As someone who occasionally has to write PowerShell, I can say with confidence
that is an abomination of a language with a horrible syntax. I hope this never
gets implemented on any other platform when there are so many superior
alternatives.

~~~
mikemaccana
Really? Log onto Windows and run:

    
    
        ps OUTLOOK.EXE | kill
    

Note the lack of any regex-munging tools? That's because PS is sending a list
of processes, not just lines of text. The constant Unix 'what's a good regex
for this or that' problem is gone because content is separate from
presentation - which as we all know is good engineering.

I'm a Unix guy. Window Server 2008R2 still requires reboots for trivial
activity (eg, installing Office web), which I don't think is appropriate for
servers. But PoSH is awesome.

~~~
snprbob86
I too am a Unix guy, but I came from a very Microsoft centric world: Microsoft
itself. There, I used PowerShell day in and day out. It's a decent little
shell. I much prefer it over cmd! That said, a better description for it would
be a REPL. And if you think about it that way, then it's a pretty damn awful
shell. It prefers to work with objects, so it tends to be frustrating to work
with bytes. Besides, I've already got a great tool for working with objects:
Python.

The bottom line is this: If you need a tool for operating on objects, then use
a programming language; preferably choose one with a strong REPL. If you need
to deal with persistent, serialized, streams of bytes, use a traditional
shell.

~~~
jkahn
I agree snprbob86, and that's what I was getting at. PowerShell doesn't know
if it's a shell or an object-based language.

It's far too verbose. It's a shell, and a huge pain to type interactively.
Yes, it has tab completion, but so does bash - and that's far less verbose.

It's also opaque. Because it's object-based, but you work with it on the
command line, it outputs in text but there is constantly "other" information
that is not displayed on screen that you can get if you pipe through to
another command. That's not intuitive. Text processing is intuitive.

It reeks of design by committee. It's own execution policy. Java-like
getter/setters. Super verbose syntax. About the only good thing PowerShell has
done is force Microsoft to provide a command-line, scriptable interface to all
their server products to get away from GUI dependency. And that's a product of
their PowerShell internal policy, not the language itself.

Yes, it's better than CMD.exe. But still a huge pain. Other platforms have
Python, Ruby, Perl... and dare I say it, bash.

~~~
contextfree
Is it really all that verbose? The full cmdlet names like Get-ChildItem etc.
are long, but there are standard abbreviations for most of them - which follow
a more consistent naming pattern than short names in most languages/shells.

------
profquail
Since no one else has mentioned it:

<http://pash.sourceforge.net/>

There's been a (partial) port of PowerShell to Linux/Mono out there for a few
years; maybe having the language spec will allow the project to go a bit
further.

------
keyle
I've limited knowledge of PowerShell but I can't see why I would want it in my
OS? Don't we have enough with bash, ksh etc.?

~~~
Niten
This isn't pointed at you, keyle, but here PowerShell seems to be one of those
things that's universally panned by people who don't understand it, or who
refuse to give a serious chance to anything that isn't a traditional Unix
shell...

To answer your question, PowerShell's big win is that it's an object-oriented
shell on top of .NET. Where the Unix shell pipes flat data, PowerShell pipes
.NET (and COM) objects.

In practice this means things that may require complicated and often fragile
text-wrangling in the Unix shell are straightforward and robust in PowerShell.
For example, suppose you wanted to kill all processes with a private working
set greater than 1 GB:

    
    
        ps | ?{ $_.PM -gt 1GB } | %{ $_.Kill() }
    

Here ps returns a collection of all current processes, then pipes it to the
where-object cmdlet (abbreviated "?") which filters the collection to those
with a private working set greater than the given size. The filtered
collection is then piped into the foreach-object cmdlet ("%") which invokes
the Kill() method on each object passed in – these are real .NET objects being
passed around, so you can invoke methods, set properties, etc.

You can get the same result with a Unix shell script, but you have to be
careful to count the columns output by ps correctly, skip the output header,
pass it through awk, save the corresponding PIDs and then invoke the kill
command on them... and then it all breaks if you run it on a different Unix
system where ps outputs a different formatting. In practice you usually leave
the shell environment and write a Perl or Python script instead for this sort
of thing.

In PowerShell you can directly instantiate .NET and COM objects, and you can
implement your own cmdlets and modules either in the PowerShell scripting
language or in any .NET language like C# or F#. So e.g. you can access the
.NET class libraries to get the time as so:

    
    
        [System.DateTime]::Now
    

And this makes PowerShell handy for interactively developing .NET class
libraries (at least until C# gets a real REPL, and if you aren't using F#
anyway). Of course this object-oriented approach is all the more necessary on
Windows, which is inherently an object-oriented system (think OLE automation,
WMI, etc., let alone .NET) than it is on Unix-based systems.

Some people will complain about the PowerShell scripting language... and sure,
it's not perfect, but I think the team did about as good a job as possible
satisfying the various requirements involved in building a new Windows shell
language that could be used both interactively and as the basis for writing
scripts. Superficially the language is heavily influenced by Perl, and while
I'd still rather use Perl for "serious" automation tasks, PowerShell gets the
job done... and it's nowhere near as ugly as scripting in the traditional Unix
shell, nevermind the old Windows command shell.

For more on the design rationale, in the words of one of PowerShell's
creators:

[http://stackoverflow.com/questions/573623/powershell-vs-
unix...](http://stackoverflow.com/questions/573623/powershell-vs-unix-
shells#573861)

~~~
angusgr
I worked with PowerShell in a past life, and found it quite useful and
reasonably pleasant[1] (esp. when coming from standard Windows Shell), however
it's this:

 _In PowerShell you can directly instantiate .NET and COM objects_

... that I think will keep it from being especially useful on non-Windows
platforms.

Windows has COM objects for pretty much every language/app/platform feature
pre-2003, and .NET objects for pretty much everything since. To be
equivalently useful, then a ported version would need to find the equivalents
on their new platform. That sounds hard to me, especially on platforms like
Linux where you have a half-dozen different desktop API possibilities and
where the historical focus is on text files, not APIs, for configuration &
control.

Without object models to leverage, a PowerShell port will be limited to
replicating everything with wrapper objects: starting from Bash functionality,
then coreutils, and then slowly working up.

[1] TBH I wish they'd added features to IronPython instead of making a new
syntax, but such is life.

~~~
Niten
> however it's this [...] that I think will keep it from being especially
> useful on non-Windows platforms.

Sure, and I acknowledge as much in my post above, that PowerShell's object
orientation is most appropriate for the Windows environment. But even if you
aren't concerned with COM, I still think PowerShell is pretty nice, and I
wouldn't mind seeing a port to Linux. So for that reason I welcome its
addition to the Community Promise.

> TBH I wish they'd added features to IronPython instead of making a new
> syntax, but such is life.

I don't think that would have worked well...

You have to keep in mind that PowerShell is intended to be used interactively,
and this has all sorts of implications for the language design. For instance
when you type

    
    
        PS > foo
    

at the PowerShell command line, "foo" may be a pure PowerShell function, but
it could also be a cmdlet, or an external command somewhere else on the
system. If this were a straight Python REPL instead, you'd have to do external
calls differently from Python function calls, like so:

    
    
        Python > system("foo")
    

and that gets old real fast. Likewise you need to allow bare strings and ditch
parentheses for function calls so you don't wind up saying cd("C:\"). You'd
also have to come up with a more succinct syntax for chaining Python
generators assuming that's what you want to use as a substitute for
PowerShell's cmdlets. Plus there are concerns like, hey, we can't use the
backslash as a string escape operator, because suck as it may, that's the
traditional path separator on Windows, so we've gotta make it something else.
By the time you're done, it's not even Python any more.

And on top of all that: in my opinion, as much as I love Python, significant
whitespace really sucks for REPLs...

So I don't think Python would have been an appropriate choice for a new
Windows command line interface. But the great thing about PowerShell is that
even if it isn't interactive Python, you can always implement cmdlets for it
in IronPython (or pretty much any other .NET language)...

~~~
angusgr
Fair enough Re: differences between Python & PowerShell syntax.

I don't entirely agree with you on the REPL point, because I use Python in a
REPL all the time (esp. with ipython.)

However, I agree with the rest. Although you could always define additional
statements (ala print in Python 2.x), it could get messy very fast.

------
Osiris
_We hope to see implementations on all of your favorite platforms. This would
benefit the industry, our partners, and our customers._

It seems they think there is a benefit for themselves to see PowerShell
implemented on other platforms.

~~~
moondowner
maybe they should say: "This would benefit Microsoft, our partners, and our
customers"

------
hexis
Can anyone explain why Microsoft uses a "Promise" instead of a "License" as
seems standard in the industry?

~~~
tzs
From what I've seen "covenant" is the most common term used for this kind of
thing. For example, here's a page I put together once to help me understand
the differences between the various patent promises that might affect ODF and
OOXML, although half the links to the originals no longer work. It shows two
Microsoft documents, a Sun documents, and the terms IBM uses for many
standards side by side, with the text colored so that sections in the
difference ones that correspond in function are colored the same. It makes it
easy to look at one and see how the others word their similar section:

<http://www.tzs.net/odfooxmlpatent.html>

In essence, a "covenant" not to sue is a fancy way of saying "promise" not to
sue.

As far as the difference between a covenant/promise and a license goes, the
courts have been unclear in their guidance. Covenants/promises may not survive
a sale of the patent--although the cases are mixed. Covenants/promises may not
provide the person they are given to the right to sell things that use the
patent to third parties (or rather, it may not apply to the third parties and
so the patent owner might be able to sue them). The case law here is murky,
too, with the latest tending to favor that the covenant/promise does apply
downstream.

I've seen cites to at least one appeals court case where the court said all
patent licenses are really just promises not to sue. That's because a patent
does not give the patent owner permission to practice the patent. It just
gives him the power to exclude others from doing so, and so he can't really
license you the right to actually make something that is covered by that
patent. All he can do is agree not to sue you if you do so.

Most of the cases, though, apply to covenants/promises to a specific party.
E.g., company X and company Y are disagreeing over X's patent, and as part of
some settlement X grants Y a promise not to sue.

Different considerations might apply when the covenant/promise/license is not
to anyone specific but is rather a non-exclusive covenant/promise/license to
everyone. When viewed as a license, this kind of license is something called a
"bare license". Bare licenses are not good for the recipient, as they can be
revoked at any time. What you really want is for the covenant/promise/grant to
be viewed as a contract. Fortunately, there is a mechanism in contract law to
allow this, called promissory estoppel. The basic idea is that if I make a
promise to you (where you can be the whole world), reasonably knowing that you
are going to rely on this promise, and you do rely on this promise and act
accordingly, then the law will enforce the promise.

~~~
kenjackson
Interesting.

So, what of soemthing like WebM? Does it have the same problems with respect
to transfer of ownership?

------
me_again
This is likely most useful for remote-controlling windows boxes from some non-
windows endpoint. I can see that being handy for a unix-centric admin forced
to admin exchange, for example.

------
leif
Considering wrapping the perl interpreter to get a performant powershell
implementation.

Extra lols from the "download spec page":

    
    
      > Supported Operating Systems:Windows 7;Windows Server 2008 R2
      > Microsoft Word or Word Viewer

------
chrisjsmith
The community promise is worthless:

<http://www.fsf.org/news/2009-07-mscp-mono>

~~~
tzs
FUD. A summary of their argument is (1) Microsoft has software not covered by
the promise, and (2) the promise only covers the patents you need to implement
the covered specification. Neither of these makes the promise worthless.

This is no more worthless than the similar promises from IBM, Sun, and many
others that cover a huge number of specifications that are widely used in open
source. It's the normal way patents are made available for free use in
implementing specifications.

~~~
lukeschlather
> The Community Promise does not give you any rights to exercise the patented
> claims. It only says that Microsoft will not sue you over claims in patents
> that it owns or controls. If Microsoft sells one of those patents, there's
> nothing stopping the buyer from suing everyone who uses the software.

Microsoft can sell the patents, and the buyer can sue you. And what happened
when Oracle bought Sun? Oracle got sue-happy. It's not like Microsoft has been
a model citizen up until now. They're actively suing manufacturers who are
using Linux, especially in the consumer space. It's not FUD - it's reality.
Microsoft is very clear about what they're planning on doing to manufacturers
who dare to ship consumer hardware that doesn't pay the Microsoft tax.

~~~
chrisjsmith
Exactly!

