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.
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...) .
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.
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.
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.
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.
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.
I've heard a lot of good things about it, mainly from people used to CMD though. When I checked it out, I didn't find a lot to do with it. I didn't feel like learning a new shell language that only works on Windows. The lack of familiar helper tools such as diff, grep and sed didn't help, and I don't know whatever Windows equivalents may exist. I'm sure if I was using Windows PWSH would be great, but like many of us I don't have any interest in using Windows as a webserver platform.
Now that there may be a prospect of using PowerShell on other platforms, I wonder why I'd bother? Day to day tasks I'm perfectly happy doing in bash, and anything more complex, I'd just as soon use Python, Ruby, PHP or Perl.
diff is an alias for Compare-Object so if you tried it, you should have seen it do something. But unlike actual diff it operates on objects rather than files, so you need to gc (Get-Content) the files you want to compare.
sed/awk: string manipulation is built-in to PowerShell, but sed's in-place file editing is replicated by piping Get-Content into Set-Content. Sometimes more verbose, sometimes not.
I personally don't see what value PowerShell would bring to other platforms, given they already have huge swathes of scripts written in well-developed (or at least well-discussed) languages and command-line tools for system administration are plentiful. But why would you bother using Perl when you already have Ruby? Obviously some people will take the choice if they know it.
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.
Yep, it has some interesting features/capabilities but the syntax is soooo baroque. All I want out of shell is a means to get boring shit done without having to think about it too much. At this point, Cygwin is STILL the way to go on windows and it would take A LOT of simplification to make powershell even competitive on windows, let alone competitive on *-nix platforms with a plain old shell like bash.
There are some very powerful commandlets (basically scripts) for control over various pieces of MicroSoft infrastructure components (Exchange, Active Directory and more). Having access to these commandlets on my favored environment would be useful. I wouldn't even need to be running a PowerShell session to run them, but that would occasionally be nice too (there is something to be said for object pipes).
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:
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.
> 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)...
Because they are not licensing a piece of software. They are promising not to sue if you implement your own compatible software. If it were software it would be licensed.
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:
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.
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.
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.
> 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.
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.