PowerShell vs. Unix Shells

Question

I'm debating whether I should learn PowerShell, or just stick with Cygwin/Perl Scripts/Unix Shell scripts, etc.

The benefit of PowerShell would be that the scripts could be more easily used by teammates that don't have cygwin; however, I don't know if I'd really be writing that many general purpose scripts, or if people would even use them.

Unix scripting is so powerful, does PowerShell come close enough to warrant switching over?

EDIT: Here are some of the specific things (or equivalents) I would be looking for in PowerShell:

• grep
• sort
• uniq
• Perl (how close does PowerShell come to Perl capabilities?)
• awk
• sed
• file (the command that gives file info)
• etc.

Answer 1

I have used a bit of Powershell for script automation. While it is very nice that the enviroment seems to have been thought out much more than Unix shells, in practice the use of objects instead of text streams is much more clunky, and a lot of the Unix facilities that have been developed in the last 30 years are still missing.

Cygwin is still my scripting environment of choice for Windows hosts. It certainly beats the alternatives in terms of getting things done.

Answer 2

If you like Shell-Scripting you will love PowerShell!

Start here: A guided tour of the Microsoft Command Shell (Ars Technica)

Answer 3

When you compare PowerShell to the combination Cygwin/Perl/Shell, be aware that PowerShell only represents the "Shell" part of that combination.

You can however invoke any command from PowerShell just as you do from cmd.exe or Cygwin. It does not re-implement the specified functions, and it is certainly not comparable to Perl.

It's "just" a shell, but it makes programming easier providing a comfortable interface to the .Net universe.

Also keep in mind that PowerShell requires WinXP, Srv2003 or higher, which may pose a problem depending on your IT infrastructure.

Update:

I had no idea what kind of philosophical debate my answer would spark.

I posted my answer in the context of the question: Compare PowerShell to Cygwin and Perl and bash.

PowerShell is a shell, as it makes no syntactic difference between built-in commands, commandlets, user functions, and external commands (.exe, .bat, .cmd). Only invoking .Net methods differ by adding a namespace or an object in the call.

Its programmability derives from .Net framework, not from anything specific to the PowerShell "language".

I'd say I believe PowerShell is a "scripting language" as soon as Bugzilla or MediaWiki are implemented as PowerShell scripts running on a web server ;)

Until then, enjoy the comparisons.

Answer 4

I am not a very experienced PowerShell user by any means, but the little bit of it that I was exposed to impressed me a great deal. You can chain the built-in cmdlets together to do just about anything that you could do at a Unix prompt, and there's some additional goodness for doing things like exporting to CSV, HTML tables, and for more in-depth sys-admin types of jobs. And if you really needed something like sed, there's always UnixUtils or GnuWin32, which you could integrate with Powershell fairly easily.

As a longtime Unix user, I did however have a bit of trouble getting used to the command naming scheme, and I certainly would have benefitted more from it if I knew more .NET.

So essentially, I say it's well worth learning it if the Windows-only-ness of it doesn't pose a problem.

Answer 5

I haven't seen that the Powershell has really taken off, at least not yet. So it might not be worth the effort of learning it unless those others on your team already know it.

For your predicament you might be better off with a scripting language that others could get behind, Perl like you mentioned, or others like Ruby or Python.

I think a lot of it depends on what you need to do. Personally I've been using Python for my own personal scripts, but I know when I start writing something that I'll never be able to pass it on - so I try not to do anything too revolutionary.

Answer 6

grep

Select-String cmdlet and -match operators work with regexes. Also you can directly make use of .NET's regex support for more advanced functionality.

sort

Sort-Object is more powerful (than I remember *nix's sort). Allowing multi-level sorting on arbitrary expressions. Here PSH's maintainance of underlying type helps; e.g. a DateTime property will be sorted as a DateTime withou having to ensure formatting into a sortable format.

uniq

Select-Object -Unique

Perl (how close does PowerShell come to Perl capabilities?)

In terms of Perl's breadth of domain specific support libraries: nowhere close (yet).

For general programming, PSH is certainly more cohesive and consistent, and easier to extend. The one gap for text munging is something equivalent to perl's .. operator.

awk

It has been long enough since using awk (must be >18 years, since later I just used perl), so can't really comment.

sed

[See above]

file (the command that gives file info)

PSH's strength here isn't so much of what it can do with filesystem objects (and it gets full information here, dir returns FileInfo or FolderInfo objects as appropriate) is that is the whole provider model.

You can treat the registry, certificate store, SQL Server, IE's RSS cache etc. as an object space navigable by the same cmdlets as the filesystem.

---

PSH is definitely the way forward on Windows. MS have made it part of their requirements for future non-home products. Hence rich support in Exchange, support in SQL Server, this is only going to expand.

A recent example of this is the TFS PowerToys. Many TFS client operations are done without having to startup tf.exe each time (which requires a new TFS server connection etc.) and is notably easier to then further process the data. As well as allowing wide access to the whole TFS client API to a greater detail than exposed in either Team Explorer of TF.exe.

Answer 7

Tools are just tools.
They help or they don't.
You need help or you don't.

If you know Unix and those tools do what you need them to do on Windows - then you are a happy guy and there is no need to learn PowerShell (unless you want to explore).

My original intent was to include a set of Unix tools in Windows and be done with it (a number of us on the team have deep Unix backgrounds and a healthy dose of respect for that community.) What I found was that this didn't really help much. The reason for that is that awk/grep/sed don't work against COM, WMI, ADSI, the Registry, the cert store, etc, etc. In other words, UNIX is an entire ecosystem self-tuned around text files. As such, text processing tools are effectively management tools. Windows is a completely different ecosystem self-tuned around APIs and Objects. That's why we invented PowerShell.

What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text.

Again - there is no religion here - our focus is on giving you the tools you need to succeed. That is why we are so passionate about feedback. Let us know where we are falling down on the job or where you don't have a tool you need and we'll put it on the list and get to it. In all honesty, we are digging ourselves out of a 30 year hole so it is going to take a while. That said, if you pick up the beta of Windows Server 2008 /R2 and/or the betas of our server products, I think you'll be shocked at how quickly that hole is getting filled.

With regard to usage - we've had > 3.5 million downloads to date. That does not include the people using it in Windows Server 2008 because it is included as an optional component and does not need a download. V2 will ship in all versions of Windows. It will be on-by-default for all editions except Server core where it is an optional component. Shortly after Windows 7/Windows Server 2008 R2 ships, we'll make V2 available on all platforms XP and above. In other words - your investment in learning will be applicable to a very large number of machines/environments.

One last comment. If/when you start to learn PowerShell, I think you'll be pretty happy. Much of the design is heavily influenced by our Unix backgrounds so while we are quite different, you'll pick it up very quickly (after you get over cussing that it isn't Unix :-) ). We know that people have a very limited budget for learning - that is why we are super hard-core about consistency. You are going to learn something and then you'll use it over and over and over again.

Experiment! Enjoy! Engage!

Jeffrey Snover [MSFT] Windows Management Partner Architect

Answer 8

I found PowerShell programming to be not worth the effort. I have several years of experience with shell scripting under Unix, but I found it enormously difficult to do much of anything with PowerShell. It seems like many functions require you to interrogate the Windows Management Interface and issue SQL-like commands to get the information you need. For example, I wanted to write a script to remove all files with a specific suffix from a directory tree. Under Unix, this would be a simple "find . -name *.xyz -exec rm {} \;" After a couple of hours dicking around with Scripting.FileSystemObject and WScript.Shell and issuing "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", I finally gave up and settled for Windows Explorer's "Search" command and just do it manually. There's probably some way to do what I wanted, but I didn't see anything obvious and all the examples on the MSDN site were so trivial as to be worthless.

EDIT Heh, of course as soon as I wrote this I poked around some more and found what I had been missing: the -recurse option to the remove-item command is faulty (revealed if you use "get-help remove-item -detailed"). I had been trying "remove-item -filter '* .xyz' -recurse" and it wasn't working, so I gave up on it. Turns out you need to use "get-childitem -filter '*.xyz' -recurse | remove-item".

Answer 9

PowerShell is very powerful, more powerful than the standard built-ins of the Unix shells (but only because it includes much of the functionality usually shelled out to subprograms). Also, consider that you can write applets in any .NET language, including IronPython, IronRuby, PerlNet, etc.. or you can simply call your cygwin commands from PowerShell, ignoring all the extra functionality and it will work similarly to bash, korn, or whatever...

Answer 10

Why would anyone want to use a proprietary tool from a software company that has a long tradition of being willing to screw over their customers and developer base if it gives them a chance to screw over their competitors?

You don't have to learn all those Unix utilities. Perl was initially written to replace all of them. if like me you abhor Perl, Python and Ruby kept up the tradition.

Answer 11

If development speed is an issue, I would suggest you postpone learning PowerShell until time allows it. The thing is, you'll spend the first few months trying to write Perl in it ( been there, with other languages ).

Answer 12

The PowerShell console window, which is what most people think of as PowerShell, cannot compare to a Unix shell like bash or ksh.

• Where is the searchable command history?
• Where are the keyboard shortcuts for command editing (back/forward word, kill word/line, paste, i-search)?
• Where's the command option tab completion?
• Why is the default pager some awful 1980's version of more without being able to page backward or do /regex searches?