What irregularities? Could you give some examples, please. Honest question here - I'm not claiming that PowerShell is perfectly regular and I would appreciate any insights.
The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.
Not true. Objects can be rendered on the terminal as well. PowerShell does this all the time. For some object types a certain format/method has been registered, but for all other types PowerShell just falls back to default rendering - which is to render the properties. You don't need *any* specific program to write objects in PowerShell. Never. One distinct advantage of this is that you can actually *choose* exactly how you want the objects written without relying on each and every little CLI tool to include a whole battery of output options. ls|ft lists files/dirs in a table (ft is alias for Format-Table): Each property in its own column. ls|fl lists files/dirs in a list (fl being an alias for Format-List): Each property on its own line. ls|fw lists files/dirs in "wide" format (fw is an alias for Format-Wide): Multiple columns with just the name. The cool thing is that ps|fl works similar: It lists processes with properties on separate lines.
you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.
PowerShell builds upon.NET, COM and WMI, which are all models which supports discoverable objects. One of the first cmdlets a powersheller learns is the gm cmdlet. gm is an alias for Get-Member. This cmdlet reflects and documents the types with properties, methods, events etc of the objects piped to it on the command line. No need for external out-of-date documentation.
This means development and testing is simple, you do it one module at a time, type the input and watch the output. And you can very easily combine different programs in a way that no one tried before.
Well, that is the same way with PowerShell. Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal using the default or registered format (or you can control the format). But PowerShell takes it a few steps further, e.g. defining common infrastructure for transactions as well as risk control such as executing all cmdlets in simulated "whatif" or "confirm" mode in a unified way and based on context so that cmdlets executing within a script will inherit the mode from the script invocation. The fact that *all* cmdlets support the -WhatIf parameter lets you try out even potentially state-changing scripts and cmdlets before actually executing them.
I don't think powershell offers any advantage over the way Unix has been working for forty years.
Frankly, based on the above it doesn't seem like you know enough about PowerShell to pass that judgement. And having worked for forty years doesn't mean that it cannot be improved. I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.
"Coolness" aside, what can be done with these objects that cannot be done with the files? As in, what end result can be achieved, I don't care about syntax.
With PowerShell those objects are.NET or COM objects. Just about every application on Windows is built upon one of these object models. This means that PowerShell can directly use the same building blocks which make up the applications. The applications become scriptable by default without the need to create CLI specific tools to manipulate the objects. Word, Excel etc. are all built this way and lends themselves to "automation" through the object model.
On Unix/Linux the applications and tools are monoliths executing in separate processes. On Windows the equivalent applications are built from discoverable components which can be used by scripting tools such as PowerShell. Important here is also the fact that PowerShell instantiates objects in-process so that even if they are designed around manipulating memory structures this will work even when combined on a command line in PowerShell.
So, the fact that "everything is an objects" means that your reach from the command line is greatly enhanced. You can script objects of applications which were never designed with CLI scripting in mind.
So catting a file is stupidly clumsy so you are pretty much forced to create an alias to make it tolerable, but of course you will normally not have created that alias and typing in the whole command without the alias is a big pain, so chances are you simply won't carry out the task that the Unix guy would have already completed while you are still trying to find a place to store your alias permanently.
And why does working with Microsoft products always turn out to be just like this?
Ahem. The GP showed you how to list the *built-in* aliases. That's right, cat is a built-in alias for Get-Content. So basically you just *assume* that Microsoft products are "just like this". You fail.
The point was the grandstanding, the comment "I do have to say Powershell is pretty sweet" implied something interesting or insightful was going on.
There is. PowerShell is a refreshing new take on shell scripting. Granted, it is best fit for Windows because Windows is already pretty much object oriented from a system point of view. But at the same time traditional shells would struggle with incorporating OO concepts. PowerShell does away with the need for sed and awk, has a built-in extremely powerful regex engine and has modern constructs like structured exceptions, script blocks, closures, integrated help (no not just man pages) and a lot of other interesting stuff like the common -whatif and -confirm parameters, remote sessions and remote jobs, fan-out remoting etc.
You may not like the fact that Windows now sports a shell which surpasses bash, ksh and zsh in many ways, but that doesn't mean that it is not interesting. It is for a good many of us.
Half of the people in this thread make it sound like this is such a big deal, and it's still a pile of steaming crap.
Yeah, whatever. You are entitled to your opinion. But please educate yourself on the subject.
It's like I've stumbled into some bizarro-world edition of Slashdot where getting a limited command shell to function under Windows is some sort of nirvana. You still have a (very very very) limited shell with little of the functionality of shells created 20+ years ago.
Translation: "Help, someone in here has something good to say about Windows and nobody helps me with bashing them. Anything coming from Windows cannot possibly bring anything new. I refuse to look at it. If it is any good, it must have existed for 20+ years in Unix".
Grow up, please. PowerShell is a full-featured command shell and surpasses bash, ksh and zsh in several areas. You may still prefer *sh shells, but on Windows there is an interesting new take on the concept.
Or, to put it simply, "there is nothing to see here". What you think of as the Rapture is a meh moment at best.
Translation: "I don't want to hear about anything which could challenge what I already know as the truth."
That showcases everything I hate about powershell right there.
That is a lot of hate for something you obviously do not know a lot about.
GP was mistaken. The command is actually Add-PSSnapin and the specific command could be written as
Add-PSSnapin VMware.VimAutomation.Core
Note how no parameter names or quotes were necessary (but still allowed).
If it were linux, the command would be somethign like "./etc/bash_completion.d/vmware"
No, that would merely set up completion. A PowerShell snapin is actually a module which can have private namespaces to avoid collision in a global namespace, it can define new drives and providers etc. It is much more than completion. In fact, completion has nothing to do with it, completion will work even for script files which define parameters without any completion registration.
What the hell is with PowerShell and switches to commands? It's like someone said "How can we possibly give users RSI by using our new interface? I've got it!! Type 700% more than they do in Linux!"
PowerShell is just being extremely consistent, something Unix could learn a lot from! And PowerShell usually takes fewer keystrokes.
Don't be fooled when someone shows you a command and spells out all of the parameter names in full. That is usually just because they tab-completed them. PowerShell supports both consistent shortening of parameter names, parameter aliases as well as positional parameters. All of these in a very consistent and predictable way. This even goes for your own scripts and functions. PowerShell automatically infers parameter names from the command definition - i.e. there is no need to register external completion. You need to do the latter in traditional shells because the commands lacks parameter metadata.
And maybe you want to hone up on your writing skills? You wrote
How exactly do you see Windows updates for all packages again?
You wrote Windows with a capital W. If you meant to hit on the fact that there's no central repository for 3rd party packages you should have left out the Windows part, like
How exactly do you see updates for all packages again?
See? not too difficult.
Anyway, having a central repository has very little to do with automating a test system. For automating setting up a test system having the packages available will do just nicely. Pathetic that you must move the goalposts to keep the illusion that Windows is no good.
This is a more complex problem than what scripting language you are going to use. Automating things is about job management, process management, signals, connecting streams and terminals, setting device modes, filesystem permissions, modifying network settings, and many other things.
Agreed. And that is what PowerShell excels at - on the Windows platform.
Unix is designed in a way that lets you change almost every property of the system in numerous ways, following general principles of its architecture. It is a very logical and consistent system.
Yes, bit the fact that Unix same up with this good idea 30 years ago does not mean that it is *the only* such system or even that the *nix way of doing things cannot be improved upon.
The problem is that Windows lacks such an modular, abstract foundation.
Are you for real? Have you any idea about Windows foundation? Unlike Unix, Windows' foundation is almost exclusively object-oriented. Most/all core API are exposed through COM which is an object-oriented foundation which allow much finer-grained access than command-line utilities and text file fiddling.
It is a much more arbitrary and inflexible system, it is not designed for putting different pieces of it together in different ways for automation.
Read up on PowerShell. PowerShell works with COM, WMI and.NET and thus can reach any part of the system and all applications which expose automation APIs or which is based on.NET.
For example, on Unix you have numerous small utilities that work together nicely by piping the output of one utility into the input of another one. Windows is really bad at doing such things, and the output format of most of its utilities is not easily machine parseable.
But those "small utilities" are really small monoliths. You cannot interact with them as they run expect through the input stream. You spawn them and listen for their output. Compare that to PowerShell manipulating objects. As an example just consider the ps command. In PowerShell it returns not text but a collection of Process objects, each describing the process. These objects can be piped through other cmdlets which can call methods on those objects, like e.g. Refresh, Kill, WaitForExit or drill down into threads or handles, all from the returned object. With Unix you have to ask the utilities to output in a certain format or use entirely separate utilities.
Consider for example why ls has so many options for controlling output (I list here only the options for somehow controlling the output format and/or sorting):
man ls
(a lot of options)
Now, is that a simple utility? I can count some 50+ formatting/sorting options in this command alone. Why does a command which is supposed to list files and directories have so many options for controlling the output format? Is it to please cranky sysadmins who will only accept to view listings in a specific format, or is to to adapt to the requirements of other commands? The constant formatting and parsing is error prone and thus commands now include options to make sure that e.g. dates can be formatted and parsed in a way as to avoid strange effects when run in a different environment.
After that consider ps which has it's own set of options for controlling output to allow for further processing. Why do all commands have to be concerned about this, often using conflicting concepts and option names? How is this "do one task only and do it well"?
Then look at PowerShells ls command (alias for Get-ChildItem):
PS> get-help ls
NAME
Get-ChildItem
SYNOPSIS
Gets the items and child items in one or more specified locations.
How exactly do you see Windows updates for all packages again? Oh, right, it's not a feature. Yawn.
Ignorance can be cured by Google (or bing). It took me 30 seconds to find out that Windows Update does indeed have a COM API which can be readily used from PowerShell. Here a way to list *all* available packages from Microsoft Update:
Title ----- Latvian Language Pack - Windows 7 Service Pack 1 (KB2483139) Slovenian Language Pack - Windows 7 Service Pack 1 (KB2483139) ( other language packs ) Definition Update for Microsoft Security Essentials - KB2310138 (Definition 1.103.1197.0)
Note how the list was produced by selecting just the title. The updates returned by the update searcher are actually objects which not only expose a lot of extra information such as disk/cpu/memory capacity recommendations, severity indicators from the security response team, knowledge base article references, license text etc, but also allows you to directly proceed to install by piping them.
I can do the same thing in 3 lines of code using only SSH and virsh in our KVM environment (1 line to set sh as shell, 1 to run SSH and use virsh to clone / create a VM, and 1 to start it).
And I can do that with 1 line of PowerShell code (PowerShell has a consistent way to short parameters, use positional parameters and pipe full objects like virtual machines):
I'm sorry. I'm really not trying to be obtuse; this is a serious question.
How is any of that different from shell scripts?
One of PowerShells roles is indeed shell scripting. As shell scripting it is really powerful and robust. It has a very consistent syntax, borrows from *nix pipe paradigm (but improved upon it with object-oriented pipes), has an very advanced scripting language with structured exception handling, optionally static/dynamic typing, closures etc.
PowerShell defines a lot of infrastructure and conventions directly aimed at shell scripting, e.g. all commands which can somehow change system state (write to files, change registry entries, delete directory entries) supports the -whatif and -confirm parameters. These allow you to run a script in simulated mode or in a mode where you are prompted to accept or reject each change. PS infrastructure makes it easy to build the same support into your own cmdlets, functions and scripts.
Shell scripting is but one of its roles. PS has also been designed to be a automation engine to be used within applications, e.g. GUI applications. The PS commands (called cmdlets) use strongly typed parameters as opposed to weakly typed (text-only) parameters in traditional shells. Also, the PS execution model is to *not* spin up external processes when executing commands, but to process the cmdlets in-process.
This means that cmdlets are really well positioned to become the back-end of a GUI application, essentially using the same class as an implementation of the command pattern in a GUI tool and as a PS cmdlet. You *can* do this with traditional *nix tools, but the text serialization/deserialization and separate-process model constantly get in the way, not to mention the fact that there are some objects which are not at all suited to be represented as text in the first place. PS cmdlets can manipulate in-process (in-memory) objects passed to them without serialization. This is what they do on the PS pipeline and what they'll do when PS is used as an in-process engine within a GUI application.
Oh? Where? We'd be hearing about it non-stop if it were happening. At the very least, Microsoft would be constantly gloating about it as loudly and publicly as possible.
Ever heard about Sony Playstation Network? They had a few servers compromised, through Apache.
Look it up. Basically if anyone acts in good faith relying on the promise (a promise here being a one-way contract where you do not have to agree to anything), the principle of *estoppel* springs into play. It is even more legally binding than a contract, because MS cannot even terminate it because of anything you may or may not do.
MS patent grant and covenant covers C# and core libraries. Unlike Java, C# and core libraries is standardized through ECMA and ISO. As part of having a standard accepted by ISO a submitter must grant license for any patent necessary for implementation on a RAND basis. This was not enough for the OS community, so MS issued the "community promise".
And yes, the community is legally binding and is even stronger than a contract as the recipients do not even have to agree to anything.
Then you don't recall correctly, obviously. Microsoft did actually develop Project Natal within its own organization (and through a wholly-owned subsidiary). They are using hardware developed by an Israeli company.
Actually someone else has began to illuminate its shortcomings so I need not bother replicating what he has already said.
Only he was wrong.
Part of the real power of Unix shells comes from a fundamental tenet of the Unix philosophy. Specifically, the rule of modularity.
And then type ls --help and witness the plethora of output-controlling options. Why does ls need to have so many options? Because this is where the Unix philosophy breaks down, that's why. ls doesn't just do one job anymore. It has been extended to care the needs of commands that usually follow it on the pipeline. Indeed, why does a command which should do one thing have any formatting options at all? And why do we have other similar commands with overlapping functionality, like find or du?
Then consider PowerShell. There ls does one job: It returns objects (filesystem objects or other objects depending on location). Formatting is left to cmdlets such as ft, fl, ft (Format-Table, Format-List and Format-Wide respectively). You can certainly argue that PowerShell is more true to the Unix philosophy than bash or bourne.
First you need to accept that PowerShell has been designed for a Windows environment where text files are a lot less important than they are on *nix. In Windows the entire API (COM,.NET and even Win32) is inherently object-oriented or lends itself easily to that model (Win32 is based on the concept of "handles").
Hence, text manipulation is not as paramount as it is on *nix. Instead, object manipulation is important. And that is what PowerShell is about.
That said, PowerShell generally views "text" as a sequence of lines which are then just instances of string objects. So any PowerShell cmdlet which is designed to manipulate a generic object will manipulate string objects.
Also, unline *sh shells, PowerShell has built-in support for regular expressions. The -match, -like, -notmatch, -notlike, -split and -join operators allows for direct regex expressions to be used against strings. For instance, to calculate frequency of each word of a file you can do this: (cat.\temp2.txt) -split '\W' | % {$freq=@{}} {$freq[$_]++} {$freq}
This command will create a 2-column table with each word on its separate line along with its frequency.
Explanation: cat is an alias for the Get-Content cmdlet which will read a file and return its content as text. -split is an operator which splits text (strings) using a regex, in this case it splits on non-word characters. This yields as stream of strings (the words of the file). This is piped through '%' (alias for the ForEach-Object cmdlet) which takes up to 3 script blocks: initialization, processing and completion. The script blocks are created using the braces. The first creates a (local) hashtable. The second script block is processed for each word and increments the word in the freq table. The last one yields the freq table as the result.
To sum up: Text processing is not terribly important in the Windows world, but PowerShell still packs in-shell capabilities comparable to those of awk and sed.
... -- in that case, by stuffing it with non-interchangeable interfaces.
Ahem. Both COM and.NET allows for interchangeable interfaces. In fact, that is where the model is superior to the "plain text" approach of Unix: Configuration files are singletons. You may develop some smart scripts to manipulate config files used sed or awk - but they will rely heavily on the format of those config files. This in turn imposes restrictions on the product vendor: They cannot change or even evolve the config file format without the risk of breaking someones scripts. With interfaces (COM,.NET or WMI or whatever) as intermediates between config stores and scripts you *can* evolve the product and still maintain perfect backwards compatibility.
It's actually the only its redeeming quality -- the language (all three of them, with all later versions and extensions) is terrible, but this is completely irrelevant because all functionality is provided by utilities called from shell, and Unix is very efficient at dealing with multiple processes communicating with each other. All interfaces can be done by passing streams of data with minimal predefined formatting -- if one cares about complex processing he can write a complex parser in one of the components
Indeed that is also the biggest weakness of this "simplicity" of byte streams: There's no accepted way to exchange contracts dynamically. The "simplicity" is fake: You just pushed the complexity on to the utilities. Those utilities may be from different vendors, developed at different times at completely unaware of each other. How do you pass a tree structure from one utility to the next? What PowerShell does is provide an extensible infrastructure on which utilities can rely to discover contracts dynamically.
Microsoft, on the other hand, looooooves its internal, non-generalized interfaces, single COM umbrella with absolutely no generalization of data formats inside. No communication is possible unless one side is designed specifically to suck on the teat of the other side.
No, COM, WMI and.NET objects are discoverable. You do not need to design anything to "specifically suck on the teat"[sic]. You can perfectly well design utilities to discover properties etc. That's what PowerShell does.
And I believe you miss the greater perspective on PowerShell. Unlike the unix shells which are designed primarily for CLI, PowerShell has been designed as a generalized scripting engine which can also be used for application scripting. You can argue that any application may use bash (or indeed just set up pipes between processes directly), but the byte-stream-only interfaces and ex-process model will be a major inhibitor. PowerShell allows cmdlets to be used in-process in the shell as well as in-process in any application. No serialization necessary to leverage cmdlets, be they from the vendor, PowerShell or 3rd party module. This is a major point and one that is sorely missing from the TFA: PowerShell offers a unification model between CLI and GUI. Is it automatic? no. Is it more adequate at that task than bash or POSIX shells? hell, yes, there's no comparison.
Sounds like a bunch of fiddly bullshit. I think i'll just use bash, thanks. There isn't anything power shell does that bash doesn't except live only on Windows.
Sure about that?
As far the other argument you've used saying what if the input or output of some command changes for bash, well, whoopdey do. I've been using bash for many years and I can't remember when last time a core utility changed and if it did, it would take what, 2 minutes to see what changed and just keep going? I think I can handle that every few years.
Yeah, and when your scripts you rely on for configuring a server farm (because it is all text based in config files) fails in a silent but subtle way and takes the farm down? When your script is executed on another system with another version or (more likely) with another system locale or even just other bash defaults?. When the sort order suddenly changes or when dates are parsed wrong due to time zone or locale settings? When you never anticipated that users may use non-printable characters in names, when columns are offset because of encoding mismatch.
Text serialization and re-parsing is brittle and error-prone. Passing along actual objects is superior to passing an error-prone text serialized format which is vulnerable to all kinds of external conditions.
The whole idea of using objects in the shell is just plain stupid and introduces unneeded complexity for very dubious benefit. No thanks.
You sure sounds really competent on the subject. Are you sure you know what an "object" is?
How about gnu screen? What does PS have as an answer to that?
Uhm. How about PowerShell ISE? Multiple sessions in multiple windows, even remote sessions.
But PS can do even better: How about being able to script multiple simultaneous sessions, coordinating execution of commands on several remote computers at once. Think GNU screen, only scriptable. Then you will *start* to grasp what PS has to offer in the multi-session, remoting department. Now add on the ability to also control *remote jobs* while still interacting with them and forwarding *remote events*. Not that I believe you will grasp those concepts at all.
That's what I thought.
No, that was what you hoped for. In your ignorance you equate your own incompetence with product weakness. Guess what, just because *you* don't know about a feature doesn't mean that it cannot be there. I suggest you work on this, otherwise you will have a problem keeping up with the tech business as it moves forward.
You click and droolers have a long way to go to get to Unix status. See you at the top.
Powershell stems from the problem that not everything is a file.
Uhm. Not quite. Arguably the scripting capabilities of Windows left something to be desired before PowerShell. It was hard to write robust scripts just with.cmd files. There was WSH with VBScript which was almost a real programming language, but also quite verbose. At the same time Windows has had superior policy-driven configuration for some time. Many task which on Linux/Unix would require you to run a script locally on a server/workstation to configure some local cfg file can on Windows be accomplished through group policies. And when GPs are applicable they are much more robust. Moving a machine between OUs may mean that other GPs take effect, and GPs may have actions defined (many pre-defined) to be taken when a policy is rolled off a machine. GPs do not remove the need for scripts entirely, but it is important to understand why Windows admins were able to put up with cmd.exe or VBScript for so long: It was sufficient.
But you may also be missing the big picture here. Most people who haven't spent time exploring PowerShell don't really appreciate the depth of it. PowerShell is a potent scripting/automation tools indeed, but it is also a hostable scripting engine which will interface with your native COM or.NET application in-process.
Why is that important? Because it is the first time we have an common tool which will actually help re-use functionality between GUI admin tools and CLI admin tools without requiring authors to duplicate functionality. Consider a GUI admin tool which implements actions using best-practice command design pattern. An "command" in that pattern is a class and it is executed by 1) instantiating it, 2) injecting command parameter values and 3) calling "invoke" or something similar where the actual processing goes on. Guess what - that is almost precisely the definition of a cmdlet. By implementing a few extra general steps (hosting a PowerShell engine) you can implement the command as a cmdlet instead. Because cmdlets can operate on rich in-process objects you don't need to serialize to text and back in order to use the commands. Voila, your application is now also scriptable from the command-line. The same cmdlets can be used from a stand-alone PowerShell engine.
This is what MS did with Exchange 2007 and 2010, SQL server etc. and are continuing to do. This is what VMWare is doing. Because the admin GUI creates cmdlet instances (or indeed entire pipelines) before executing them using the resident PS engine, they can also tell you what the pipelines/scripts look like. What you are seeing is a unification of the GUI and CLI - not a move away from GUIs.
In Unix you can parse processes, logs, and system config files because everything is a file and can be run from the command line. In Windows it uses the horrible registry and you have to interface with WMI (I assume I never used powershell) with some.NET api, and programs do not leave text files for configuration.
PowerShell exposes the registry as just another "location type". You can jump into the registry and navigate it like a file system. Indeed, this model is extensible and you can administer AD, Exchange and SQL Server by navigating them as "directory" trees. The "files" (now generalized as "items") may be users, mailboxes, SQL tables. And you use the familar cmdlets such as rm for removing items.
In Unix you run a shell script with awk or sed or even Perl if it is a newer script and could take care of most anything. That makes it rock for a server.
Yes, it is robust and it has indeed served Unix well. However, those scripts will typically need to run *at* the server, which is a minor inconvenience. More importantly perhaps, is the fact that config files change with versions of the software. Which makes text-manipulation of config files brittle. It breaks enc
Powershell slow? Go ahead its easy to pick a simple task, write it in powershell (maybe a sort or nested loop counter?) then write it in C#. Even just launching powershell is enough to make me want to use bash (or make a.NET app).
Ingenius! Because PowerShell is slower than C# for tight inner loops you would rather use bash? Why am I not surprised that you have problems with Windows 7?
How about horses for courses? Use PowerShell for admin tasks you want to automate, like you would use *sh on Linux/Unix.
And when comparing command-line interpreted languages PowerShell may not beat Python, but it sure holds its own against bash (on my old rig with an AMD x2 5000+):
time for((i=0;i<1000000;i++)); do a=$((i-a)); done
Execution time: 0m19.105s = 19105ms
So, bash is 5 time slower for tight inner loops. I guess that on Linux you will use C instead of bash any time - even for automating sysadmin tasks, right?
Get real. Tools like PowerShell and bash were never meant to be fast in tight inner loops. Thus even this comparison is unfair and totally irrelevant. Bringing up topics like this is evidence of someone who needs something to attack - no matter whether it is relevant or not. In short your reasoning technical skills makes it perfectly clear why you may believe you have problems with Windows 7.
Server Core. Haha aha ha ha. Yeah, great. Now get a unix OS and see what a real headless/GUI-less system can do.
Mature. Nice. oh by the way: You obviously has little clue about core.
It needs SSH, for secure remote login, remote file copying and remote command execution. Of course, somebody at Microsoft is right now programming a really shit set of updates for powershell to try and copy SSH, but they'll get it wrong, naturally.
Obviously you know as little about PowerShell as you do about Server Core. PowerShell does remoting fully encrypted and integrated with your directory (if you so wish). And you don't even have to "jump into" the remote machine to administer it. You can just issue commands for remote machines, like e.g. icm myserver {ps} to get a list of processes running on myserver (icm is a built-in alias for Invoke-Command)
But you can *also* start sessions with any number of remote machines to and issue commands to them at will without leaving the sessions. The state of each session (think env vars etc) are preserved between command invocations. This can only be done with bash with some not-some-simple juggling and suspending.
A single command can be trivially set to execute on any number of remote hosts and consolidate the results back icm host1,host2,host3,host4 {ps} will bring up a list of all processes running on the 4 hosts. On top of that PowerShell does remote jobs. Yes, you can start jobs on remote machines and interact with them like they were jobs on the local machine, i.e. fill in the requests for console inputs, poll for partial results or progress or simply wait for completion.
I will say PowerShell is an improvement. I do think it borders on counterproductive pride as to why they don't have anything quite as simple as plain-ol-bash.
The reason why they would not run with something like bash is quite obvious when you think about it: Windows if almost entirely object-oriented, especially when you look at it through the various APIs: COM,.NET, WMI etc. Even Win32 with its handle-centric approach fall into this category.
A primary task of a command shell is to interface with the operating system and with the applications which run upon in. When all those applications expose their functionality as OO APIs, it makes a lot of sense to make the command shell object-oriented as well. That the OO nature of the shell then also drastically improves on the original paradigm of piping is just an extra.
Also, why they don't implement SSH for a nice common protocol instead of their WMI crap for remote command execution.
PowerShell can actually run over telnet or ssh or whatever. But once you look into the remoting capabilities of PowerShell v2 even SSH starts to look a little archaic. Compared to SSH it is so easy to step in and out of remote sessions, juggling several active remote sessions at the same time - even scripted - and issue commands which relay back not only the results is a seamless fashion but will even relay back progress indicators and input requests. The PowerShell fan-out remoting feature lets you issue the same command (e.g. "backup") to ten or hundreds of hosts *simultaneously* and have each one report back the output *objects* consolidated in the command result, each indicated with the host. I'm not missing SSH one iota.
Slashdot Mirror
Well,,, apart from the language still having no formal specification and (therefore?) some unfortunate irregularities in the implementation.
The language specification: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=509b77d0-5e5f-4194-a2d0-61648abfd093
What irregularities? Could you give some examples, please. Honest question here - I'm not claiming that PowerShell is perfectly regular and I would appreciate any insights.
The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.
Not true. Objects can be rendered on the terminal as well. PowerShell does this all the time. For some object types a certain format/method has been registered, but for all other types PowerShell just falls back to default rendering - which is to render the properties. You don't need *any* specific program to write objects in PowerShell. Never. One distinct advantage of this is that you can actually *choose* exactly how you want the objects written without relying on each and every little CLI tool to include a whole battery of output options.
ls|ft lists files/dirs in a table (ft is alias for Format-Table): Each property in its own column.
ls|fl lists files/dirs in a list (fl being an alias for Format-List): Each property on its own line.
ls|fw lists files/dirs in "wide" format (fw is an alias for Format-Wide): Multiple columns with just the name.
The cool thing is that ps|fl works similar: It lists processes with properties on separate lines.
you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.
PowerShell builds upon .NET, COM and WMI, which are all models which supports discoverable objects. One of the first cmdlets a powersheller learns is the gm cmdlet. gm is an alias for Get-Member. This cmdlet reflects and documents the types with properties, methods, events etc of the objects piped to it on the command line. No need for external out-of-date documentation.
This means development and testing is simple, you do it one module at a time, type the input and watch the output. And you can very easily combine different programs in a way that no one tried before.
Well, that is the same way with PowerShell. Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal using the default or registered format (or you can control the format). But PowerShell takes it a few steps further, e.g. defining common infrastructure for transactions as well as risk control such as executing all cmdlets in simulated "whatif" or "confirm" mode in a unified way and based on context so that cmdlets executing within a script will inherit the mode from the script invocation. The fact that *all* cmdlets support the -WhatIf parameter lets you try out even potentially state-changing scripts and cmdlets before actually executing them.
I don't think powershell offers any advantage over the way Unix has been working for forty years.
Frankly, based on the above it doesn't seem like you know enough about PowerShell to pass that judgement. And having worked for forty years doesn't mean that it cannot be improved. I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.
"Coolness" aside, what can be done with these objects that cannot be done with the files? As in, what end result can be achieved, I don't care about syntax.
With PowerShell those objects are .NET or COM objects. Just about every application on Windows is built upon one of these object models. This means that PowerShell can directly use the same building blocks which make up the applications. The applications become scriptable by default without the need to create CLI specific tools to manipulate the objects. Word, Excel etc. are all built this way and lends themselves to "automation" through the object model.
On Unix/Linux the applications and tools are monoliths executing in separate processes. On Windows the equivalent applications are built from discoverable components which can be used by scripting tools such as PowerShell. Important here is also the fact that PowerShell instantiates objects in-process so that even if they are designed around manipulating memory structures this will work even when combined on a command line in PowerShell.
So, the fact that "everything is an objects" means that your reach from the command line is greatly enhanced. You can script objects of applications which were never designed with CLI scripting in mind.
So catting a file is stupidly clumsy so you are pretty much forced to create an alias to make it tolerable, but of course you will normally not have created that alias and typing in the whole command without the alias is a big pain, so chances are you simply won't carry out the task that the Unix guy would have already completed while you are still trying to find a place to store your alias permanently.
And why does working with Microsoft products always turn out to be just like this?
Ahem. The GP showed you how to list the *built-in* aliases. That's right, cat is a built-in alias for Get-Content. So basically you just *assume* that Microsoft products are "just like this". You fail.
The point was the grandstanding, the comment "I do have to say Powershell is pretty sweet" implied something interesting or insightful was going on.
There is. PowerShell is a refreshing new take on shell scripting. Granted, it is best fit for Windows because Windows is already pretty much object oriented from a system point of view. But at the same time traditional shells would struggle with incorporating OO concepts. PowerShell does away with the need for sed and awk, has a built-in extremely powerful regex engine and has modern constructs like structured exceptions, script blocks, closures, integrated help (no not just man pages) and a lot of other interesting stuff like the common -whatif and -confirm parameters, remote sessions and remote jobs, fan-out remoting etc.
You may not like the fact that Windows now sports a shell which surpasses bash, ksh and zsh in many ways, but that doesn't mean that it is not interesting. It is for a good many of us.
Half of the people in this thread make it sound like this is such a big deal, and it's still a pile of steaming crap.
Yeah, whatever. You are entitled to your opinion. But please educate yourself on the subject.
It's like I've stumbled into some bizarro-world edition of Slashdot where getting a limited command shell to function under Windows is some sort of nirvana. You still have a (very very very) limited shell with little of the functionality of shells created 20+ years ago.
Translation: "Help, someone in here has something good to say about Windows and nobody helps me with bashing them. Anything coming from Windows cannot possibly bring anything new. I refuse to look at it. If it is any good, it must have existed for 20+ years in Unix".
Grow up, please. PowerShell is a full-featured command shell and surpasses bash, ksh and zsh in several areas. You may still prefer *sh shells, but on Windows there is an interesting new take on the concept.
Or, to put it simply, "there is nothing to see here". What you think of as the Rapture is a meh moment at best.
Translation: "I don't want to hear about anything which could challenge what I already know as the truth."
#Load VMWare snap-in for powershell
LoadSnapin -PSSnapinName "VMware.VimAutomation.Core"
That showcases everything I hate about powershell right there.
That is a lot of hate for something you obviously do not know a lot about.
GP was mistaken. The command is actually Add-PSSnapin and the specific command could be written as
Add-PSSnapin VMware.VimAutomation.Core
Note how no parameter names or quotes were necessary (but still allowed).
If it were linux, the command would be somethign like ". /etc/bash_completion.d/vmware"
No, that would merely set up completion. A PowerShell snapin is actually a module which can have private namespaces to avoid collision in a global namespace, it can define new drives and providers etc. It is much more than completion. In fact, completion has nothing to do with it, completion will work even for script files which define parameters without any completion registration.
What the hell is with PowerShell and switches to commands? It's like someone said "How can we possibly give users RSI by using our new interface? I've got it!! Type 700% more than they do in Linux!"
PowerShell is just being extremely consistent, something Unix could learn a lot from! And PowerShell usually takes fewer keystrokes.
Don't be fooled when someone shows you a command and spells out all of the parameter names in full. That is usually just because they tab-completed them. PowerShell supports both consistent shortening of parameter names, parameter aliases as well as positional parameters. All of these in a very consistent and predictable way. This even goes for your own scripts and functions. PowerShell automatically infers parameter names from the command definition - i.e. there is no need to register external completion. You need to do the latter in traditional shells because the commands lacks parameter metadata.
And maybe you want to hone up on your writing skills? You wrote
How exactly do you see Windows updates for all packages again?
You wrote Windows with a capital W. If you meant to hit on the fact that there's no central repository for 3rd party packages you should have left out the Windows part, like
How exactly do you see updates for all packages again?
See? not too difficult.
Anyway, having a central repository has very little to do with automating a test system. For automating setting up a test system having the packages available will do just nicely. Pathetic that you must move the goalposts to keep the illusion that Windows is no good.
This is a more complex problem than what scripting language you are going to use. Automating things is about job management, process management, signals, connecting streams and terminals, setting device modes, filesystem permissions, modifying network settings, and many other things.
Agreed. And that is what PowerShell excels at - on the Windows platform.
Unix is designed in a way that lets you change almost every property of the system in numerous ways, following general principles of its architecture. It is a very logical and consistent system.
Yes, bit the fact that Unix same up with this good idea 30 years ago does not mean that it is *the only* such system or even that the *nix way of doing things cannot be improved upon.
The problem is that Windows lacks such an modular, abstract foundation.
Are you for real? Have you any idea about Windows foundation? Unlike Unix, Windows' foundation is almost exclusively object-oriented. Most/all core API are exposed through COM which is an object-oriented foundation which allow much finer-grained access than command-line utilities and text file fiddling.
It is a much more arbitrary and inflexible system, it is not designed for putting different pieces of it together in different ways for automation.
Read up on PowerShell. PowerShell works with COM, WMI and .NET and thus can reach any part of the system and all applications which expose automation APIs or which is based on .NET.
For example, on Unix you have numerous small utilities that work together nicely by piping the output of one utility into the input of another one. Windows is really bad at doing such things, and the output format of most of its utilities is not easily machine parseable.
But those "small utilities" are really small monoliths. You cannot interact with them as they run expect through the input stream. You spawn them and listen for their output. Compare that to PowerShell manipulating objects. As an example just consider the ps command. In PowerShell it returns not text but a collection of Process objects, each describing the process. These objects can be piped through other cmdlets which can call methods on those objects, like e.g. Refresh, Kill, WaitForExit or drill down into threads or handles, all from the returned object. With Unix you have to ask the utilities to output in a certain format or use entirely separate utilities.
Consider for example why ls has so many options for controlling output (I list here only the options for somehow controlling the output format and/or sorting):
man ls
(a lot of options)
Now, is that a simple utility? I can count some 50+ formatting/sorting options in this command alone. Why does a command which is supposed to list files and directories have so many options for controlling the output format? Is it to please cranky sysadmins who will only accept to view listings in a specific format, or is to to adapt to the requirements of other commands? The constant formatting and parsing is error prone and thus commands now include options to make sure that e.g. dates can be formatted and parsed in a way as to avoid strange effects when run in a different environment.
After that consider ps which has it's own set of options for controlling output to allow for further processing. Why do all commands have to be concerned about this, often using conflicting concepts and option names? How is this "do one task only and do it well"?
Then look at PowerShells ls command (alias for Get-ChildItem):
PS> get-help ls
NAME
Get-ChildItem
SYNOPSIS
Gets the items and child items in one or more specified locations.
SYNTAX
How exactly do you see Windows updates for all packages again? Oh, right, it's not a feature. Yawn.
Ignorance can be cured by Google (or bing). It took me 30 seconds to find out that Windows Update does indeed have a COM API which can be readily used from PowerShell. Here a way to list *all* available packages from Microsoft Update:
PS C:\Windows\system32> $mus = new-object -com "Microsoft.Update.Session"
PS C:\Windows\system32> $updates = $mus.CreateUpdateSearcher().Search("") | select -exp updates
PS C:\Windows\system32> $updates|select title
Title
-----
Latvian Language Pack - Windows 7 Service Pack 1 (KB2483139)
Slovenian Language Pack - Windows 7 Service Pack 1 (KB2483139)
( other language packs )
Definition Update for Microsoft Security Essentials - KB2310138 (Definition 1.103.1197.0)
Note how the list was produced by selecting just the title. The updates returned by the update searcher are actually objects which not only expose a lot of extra information such as disk/cpu/memory capacity recommendations, severity indicators from the security response team, knowledge base article references, license text etc, but also allows you to directly proceed to install by piping them.
I can do the same thing in 3 lines of code using only SSH and virsh in our KVM environment (1 line to set sh as shell, 1 to run SSH and use virsh to clone / create a VM, and 1 to start it).
And I can do that with 1 line of PowerShell code (PowerShell has a consistent way to short parameters, use positional parameters and pipe full objects like virtual machines):
new-vm ESX01 -name NewVM_01 -templ TemplateName | start-vm
Your point? The OP was asking what to use to set up and administer test systems in a *Windows* environment. PowerShell is a valid option for that.
I'm sorry. I'm really not trying to be obtuse; this is a serious question.
How is any of that different from shell scripts?
One of PowerShells roles is indeed shell scripting. As shell scripting it is really powerful and robust. It has a very consistent syntax, borrows from *nix pipe paradigm (but improved upon it with object-oriented pipes), has an very advanced scripting language with structured exception handling, optionally static/dynamic typing, closures etc.
PowerShell defines a lot of infrastructure and conventions directly aimed at shell scripting, e.g. all commands which can somehow change system state (write to files, change registry entries, delete directory entries) supports the -whatif and -confirm parameters. These allow you to run a script in simulated mode or in a mode where you are prompted to accept or reject each change. PS infrastructure makes it easy to build the same support into your own cmdlets, functions and scripts.
Shell scripting is but one of its roles. PS has also been designed to be a automation engine to be used within applications, e.g. GUI applications. The PS commands (called cmdlets) use strongly typed parameters as opposed to weakly typed (text-only) parameters in traditional shells. Also, the PS execution model is to *not* spin up external processes when executing commands, but to process the cmdlets in-process.
This means that cmdlets are really well positioned to become the back-end of a GUI application, essentially using the same class as an implementation of the command pattern in a GUI tool and as a PS cmdlet. You *can* do this with traditional *nix tools, but the text serialization/deserialization and separate-process model constantly get in the way, not to mention the fact that there are some objects which are not at all suited to be represented as text in the first place. PS cmdlets can manipulate in-process (in-memory) objects passed to them without serialization. This is what they do on the PS pipeline and what they'll do when PS is used as an in-process engine within a GUI application.
so many exploited Linux servers
Oh? Where?
We'd be hearing about it non-stop if it were happening. At the very least, Microsoft would be constantly gloating about it as loudly and publicly as possible.
Ever heard about Sony Playstation Network? They had a few servers compromised, through Apache.
It may be legally binding on Microsoft. It's not legally binding on anyone Microsoft may choose to sell the patents to.
FUD
Look it up. Basically if anyone acts in good faith relying on the promise (a promise here being a one-way contract where you do not have to agree to anything), the principle of *estoppel* springs into play. It is even more legally binding than a contract, because MS cannot even terminate it because of anything you may or may not do.
MS patent grant and covenant covers C# and core libraries. Unlike Java, C# and core libraries is standardized through ECMA and ISO. As part of having a standard accepted by ISO a submitter must grant license for any patent necessary for implementation on a RAND basis. This was not enough for the OS community, so MS issued the "community promise".
And yes, the community is legally binding and is even stronger than a contract as the recipients do not even have to agree to anything.
Enough FUD already
Then you don't recall correctly, obviously. Microsoft did actually develop Project Natal within its own organization (and through a wholly-owned subsidiary). They are using hardware developed by an Israeli company.
Actually someone else has began to illuminate its shortcomings so I need not bother replicating what he has already said.
Only he was wrong.
Part of the real power of Unix shells comes from a fundamental tenet of the Unix philosophy. Specifically, the rule of modularity.
And then type ls --help and witness the plethora of output-controlling options. Why does ls need to have so many options? Because this is where the Unix philosophy breaks down, that's why. ls doesn't just do one job anymore. It has been extended to care the needs of commands that usually follow it on the pipeline. Indeed, why does a command which should do one thing have any formatting options at all? And why do we have other similar commands with overlapping functionality, like find or du?
Then consider PowerShell. There ls does one job: It returns objects (filesystem objects or other objects depending on location). Formatting is left to cmdlets such as ft, fl, ft (Format-Table, Format-List and Format-Wide respectively). You can certainly argue that PowerShell is more true to the Unix philosophy than bash or bourne.
First you need to accept that PowerShell has been designed for a Windows environment where text files are a lot less important than they are on *nix. In Windows the entire API (COM, .NET and even Win32) is inherently object-oriented or lends itself easily to that model (Win32 is based on the concept of "handles").
Hence, text manipulation is not as paramount as it is on *nix. Instead, object manipulation is important. And that is what PowerShell is about.
That said, PowerShell generally views "text" as a sequence of lines which are then just instances of string objects. So any PowerShell cmdlet which is designed to manipulate a generic object will manipulate string objects.
Also, unline *sh shells, PowerShell has built-in support for regular expressions. The -match, -like, -notmatch, -notlike, -split and -join operators allows for direct regex expressions to be used against strings. For instance, to calculate frequency of each word of a file you can do this:
.\temp2.txt) -split '\W' | % {$freq=@{}} {$freq[$_]++} {$freq}
(cat
This command will create a 2-column table with each word on its separate line along with its frequency.
Explanation: cat is an alias for the Get-Content cmdlet which will read a file and return its content as text. -split is an operator which splits text (strings) using a regex, in this case it splits on non-word characters. This yields as stream of strings (the words of the file). This is piped through '%' (alias for the ForEach-Object cmdlet) which takes up to 3 script blocks: initialization, processing and completion. The script blocks are created using the braces. The first creates a (local) hashtable. The second script block is processed for each word and increments the word in the freq table. The last one yields the freq table as the result.
To sum up: Text processing is not terribly important in the Windows world, but PowerShell still packs in-shell capabilities comparable to those of awk and sed.
... -- in that case, by stuffing it with non-interchangeable interfaces.
Ahem. Both COM and .NET allows for interchangeable interfaces. In fact, that is where the model is superior to the "plain text" approach of Unix: Configuration files are singletons. You may develop some smart scripts to manipulate config files used sed or awk - but they will rely heavily on the format of those config files. This in turn imposes restrictions on the product vendor: They cannot change or even evolve the config file format without the risk of breaking someones scripts. With interfaces (COM, .NET or WMI or whatever) as intermediates between config stores and scripts you *can* evolve the product and still maintain perfect backwards compatibility.
It's actually the only its redeeming quality -- the language (all three of them, with all later versions and extensions) is terrible, but this is completely irrelevant because all functionality is provided by utilities called from shell, and Unix is very efficient at dealing with multiple processes communicating with each other. All interfaces can be done by passing streams of data with minimal predefined formatting -- if one cares about complex processing he can write a complex parser in one of the components
Indeed that is also the biggest weakness of this "simplicity" of byte streams: There's no accepted way to exchange contracts dynamically. The "simplicity" is fake: You just pushed the complexity on to the utilities. Those utilities may be from different vendors, developed at different times at completely unaware of each other. How do you pass a tree structure from one utility to the next? What PowerShell does is provide an extensible infrastructure on which utilities can rely to discover contracts dynamically.
Microsoft, on the other hand, looooooves its internal, non-generalized interfaces, single COM umbrella with absolutely no generalization of data formats inside. No communication is possible unless one side is designed specifically to suck on the teat of the other side.
No, COM, WMI and .NET objects are discoverable. You do not need to design anything to "specifically suck on the teat"[sic]. You can perfectly well design utilities to discover properties etc. That's what PowerShell does.
And I believe you miss the greater perspective on PowerShell. Unlike the unix shells which are designed primarily for CLI, PowerShell has been designed as a generalized scripting engine which can also be used for application scripting. You can argue that any application may use bash (or indeed just set up pipes between processes directly), but the byte-stream-only interfaces and ex-process model will be a major inhibitor. PowerShell allows cmdlets to be used in-process in the shell as well as in-process in any application. No serialization necessary to leverage cmdlets, be they from the vendor, PowerShell or 3rd party module. This is a major point and one that is sorely missing from the TFA: PowerShell offers a unification model between CLI and GUI. Is it automatic? no. Is it more adequate at that task than bash or POSIX shells? hell, yes, there's no comparison.
Yes, but windows does have some rather lax security out of the box.
Citation needed.
Sounds like a bunch of fiddly bullshit. I think i'll just use bash, thanks. There isn't anything power shell does that bash doesn't except live only on Windows.
Sure about that?
As far the other argument you've used saying what if the input or output of some command changes for bash, well, whoopdey do. I've been using bash for many years and I can't remember when last time a core utility changed and if it did, it would take what, 2 minutes to see what changed and just keep going? I think I can handle that every few years.
Yeah, and when your scripts you rely on for configuring a server farm (because it is all text based in config files) fails in a silent but subtle way and takes the farm down? When your script is executed on another system with another version or (more likely) with another system locale or even just other bash defaults?. When the sort order suddenly changes or when dates are parsed wrong due to time zone or locale settings? When you never anticipated that users may use non-printable characters in names, when columns are offset because of encoding mismatch.
Text serialization and re-parsing is brittle and error-prone. Passing along actual objects is superior to passing an error-prone text serialized format which is vulnerable to all kinds of external conditions.
The whole idea of using objects in the shell is just plain stupid and introduces unneeded complexity for very dubious benefit. No thanks.
You sure sounds really competent on the subject. Are you sure you know what an "object" is?
How about gnu screen? What does PS have as an answer to that?
Uhm. How about PowerShell ISE? Multiple sessions in multiple windows, even remote sessions.
But PS can do even better: How about being able to script multiple simultaneous sessions, coordinating execution of commands on several remote computers at once. Think GNU screen, only scriptable. Then you will *start* to grasp what PS has to offer in the multi-session, remoting department. Now add on the ability to also control *remote jobs* while still interacting with them and forwarding *remote events*. Not that I believe you will grasp those concepts at all.
That's what I thought.
No, that was what you hoped for. In your ignorance you equate your own incompetence with product weakness. Guess what, just because *you* don't know about a feature doesn't mean that it cannot be there. I suggest you work on this, otherwise you will have a problem keeping up with the tech business as it moves forward.
You click and droolers have a long way to go to get to Unix status. See you at the top.
Mature.
Powershell stems from the problem that not everything is a file.
Uhm. Not quite. Arguably the scripting capabilities of Windows left something to be desired before PowerShell. It was hard to write robust scripts just with .cmd files. There was WSH with VBScript which was almost a real programming language, but also quite verbose. At the same time Windows has had superior policy-driven configuration for some time. Many task which on Linux/Unix would require you to run a script locally on a server/workstation to configure some local cfg file can on Windows be accomplished through group policies. And when GPs are applicable they are much more robust. Moving a machine between OUs may mean that other GPs take effect, and GPs may have actions defined (many pre-defined) to be taken when a policy is rolled off a machine. GPs do not remove the need for scripts entirely, but it is important to understand why Windows admins were able to put up with cmd.exe or VBScript for so long: It was sufficient.
But you may also be missing the big picture here. Most people who haven't spent time exploring PowerShell don't really appreciate the depth of it. PowerShell is a potent scripting/automation tools indeed, but it is also a hostable scripting engine which will interface with your native COM or .NET application in-process.
Why is that important? Because it is the first time we have an common tool which will actually help re-use functionality between GUI admin tools and CLI admin tools without requiring authors to duplicate functionality. Consider a GUI admin tool which implements actions using best-practice command design pattern. An "command" in that pattern is a class and it is executed by 1) instantiating it, 2) injecting command parameter values and 3) calling "invoke" or something similar where the actual processing goes on. Guess what - that is almost precisely the definition of a cmdlet. By implementing a few extra general steps (hosting a PowerShell engine) you can implement the command as a cmdlet instead. Because cmdlets can operate on rich in-process objects you don't need to serialize to text and back in order to use the commands. Voila, your application is now also scriptable from the command-line. The same cmdlets can be used from a stand-alone PowerShell engine.
This is what MS did with Exchange 2007 and 2010, SQL server etc. and are continuing to do. This is what VMWare is doing. Because the admin GUI creates cmdlet instances (or indeed entire pipelines) before executing them using the resident PS engine, they can also tell you what the pipelines/scripts look like. What you are seeing is a unification of the GUI and CLI - not a move away from GUIs.
In Unix you can parse processes, logs, and system config files because everything is a file and can be run from the command line. In Windows it uses the horrible registry and you have to interface with WMI (I assume I never used powershell) with some .NET api, and programs do not leave text files for configuration.
PowerShell exposes the registry as just another "location type". You can jump into the registry and navigate it like a file system. Indeed, this model is extensible and you can administer AD, Exchange and SQL Server by navigating them as "directory" trees. The "files" (now generalized as "items") may be users, mailboxes, SQL tables. And you use the familar cmdlets such as rm for removing items.
In Unix you run a shell script with awk or sed or even Perl if it is a newer script and could take care of most anything. That makes it rock for a server.
Yes, it is robust and it has indeed served Unix well. However, those scripts will typically need to run *at* the server, which is a minor inconvenience. More importantly perhaps, is the fact that config files change with versions of the software. Which makes text-manipulation of config files brittle. It breaks enc
Powershell slow? Go ahead its easy to pick a simple task, write it in powershell (maybe a sort or nested loop counter?) then write it in C#. Even just launching powershell is enough to make me want to use bash (or make a .NET app).
Ingenius! Because PowerShell is slower than C# for tight inner loops you would rather use bash? Why am I not surprised that you have problems with Windows 7?
How about horses for courses? Use PowerShell for admin tasks you want to automate, like you would use *sh on Linux/Unix.
And when comparing command-line interpreted languages PowerShell may not beat Python, but it sure holds its own against bash (on my old rig with an AMD x2 5000+):
PowerShell (Windows 7):
measure-command {for($i=0;$i -lt 1000000;$i++) {$a=$i-$a} }
Execution time: 4338.4254 ms
bash (Ubuntu 10.10):
time for((i=0;i<1000000;i++)); do a=$((i-a)); done
Execution time: 0m19.105s = 19105ms
So, bash is 5 time slower for tight inner loops. I guess that on Linux you will use C instead of bash any time - even for automating sysadmin tasks, right?
Get real. Tools like PowerShell and bash were never meant to be fast in tight inner loops. Thus even this comparison is unfair and totally irrelevant. Bringing up topics like this is evidence of someone who needs something to attack - no matter whether it is relevant or not. In short your reasoning technical skills makes it perfectly clear why you may believe you have problems with Windows 7.
Server Core. Haha aha ha ha. Yeah, great. Now get a unix OS and see what a real headless/GUI-less system can do.
Mature. Nice. oh by the way: You obviously has little clue about core.
It needs SSH, for secure remote login, remote file copying and remote command execution. Of course, somebody at Microsoft is right now programming a really shit set of updates for powershell to try and copy SSH, but they'll get it wrong, naturally.
Obviously you know as little about PowerShell as you do about Server Core. PowerShell does remoting fully encrypted and integrated with your directory (if you so wish). And you don't even have to "jump into" the remote machine to administer it. You can just issue commands for remote machines, like e.g. icm myserver {ps} to get a list of processes running on myserver (icm is a built-in alias for Invoke-Command)
But you can *also* start sessions with any number of remote machines to and issue commands to them at will without leaving the sessions. The state of each session (think env vars etc) are preserved between command invocations. This can only be done with bash with some not-some-simple juggling and suspending.
A single command can be trivially set to execute on any number of remote hosts and consolidate the results back icm host1,host2,host3,host4 {ps} will bring up a list of all processes running on the 4 hosts. On top of that PowerShell does remote jobs. Yes, you can start jobs on remote machines and interact with them like they were jobs on the local machine, i.e. fill in the requests for console inputs, poll for partial results or progress or simply wait for completion.
I will say PowerShell is an improvement. I do think it borders on counterproductive pride as to why they don't have anything quite as simple as plain-ol-bash.
The reason why they would not run with something like bash is quite obvious when you think about it: Windows if almost entirely object-oriented, especially when you look at it through the various APIs: COM, .NET, WMI etc. Even Win32 with its handle-centric approach fall into this category.
A primary task of a command shell is to interface with the operating system and with the applications which run upon in. When all those applications expose their functionality as OO APIs, it makes a lot of sense to make the command shell object-oriented as well. That the OO nature of the shell then also drastically improves on the original paradigm of piping is just an extra.
Also, why they don't implement SSH for a nice common protocol instead of their WMI crap for remote command execution.
PowerShell can actually run over telnet or ssh or whatever. But once you look into the remoting capabilities of PowerShell v2 even SSH starts to look a little archaic. Compared to SSH it is so easy to step in and out of remote sessions, juggling several active remote sessions at the same time - even scripted - and issue commands which relay back not only the results is a seamless fashion but will even relay back progress indicators and input requests. The PowerShell fan-out remoting feature lets you issue the same command (e.g. "backup") to ten or hundreds of hosts *simultaneously* and have each one report back the output *objects* consolidated in the command result, each indicated with the host. I'm not missing SSH one iota.