You have that guarantee starting with Windows 7. Version is one thing; some nice things are available only in v3+, but v2 is very usable already. Execution policy is another matter, but you can always supply a batch file with the PowerShell script containing
That's what I usually do, which is also helpful for colleagues who have no idea how to run a PowerShell script because just double-clicking it doesn't work.
Often I start with a batch file, just to notice after a dozen lines that this sort of thing is much easier to write and maintain in another language. And in the last two years I shifted more to PowerShell than batch in many cases. Some of that is surely due to atrocities like Windows XP dying out and Vista never being common. For scripts that developers execute on their machines PowerShell should be a fairly safe bet in a Windows environment by now. Deployment or build scripts should probably be MSBuild or something similar.
| You have that guarantee starting with Windows 7. Version is one thing; some nice things are available only in v3+, but v2 is very usable already.
I love me some Powershell. Wrote my first non-trivial PS script in early 2010 that was a major component to building something I would now call "Continuous deployment of Windows OS images."
But I still have way more lines of BAT in production than PS1 because the versioning is a nightmare. v2 was the first really usable release and it ran everywhere I cared about except for Windows PE. v3 got some nice enhancements and support for Windows PE, but dropped support for anything older than Windows 2008. v4 added some more but took away Windows 2008 R1.
If it were just that newer versions of Powershell offered new modules and cmdlets it wouldn't be such a big deal, but the syntax itself has been evolving. This is valid in PS v3+ but not in PS v1/2:
Many landmines are out there waiting if you need to write a script that can handle multiple Powershell versions.
There are plenty of sucky things about BAT files... But they are truly lowest-common-denominator on any Windows system, there aren't any syntactical landmines waiting to get you with different Windows versions since 2003, and for anything you want to do on Windows that you can do with Powershell you will certainly be able to find a command-line tool that lets you do the same thing with Batch.
This is not an example of evolving syntax. It's just a bunch of parameter sets added to Where-Object. New syntax is the -in operator for example (reverse of -contains).
However, I find myself using the new parameter sets for Where-Object very infrequently. Since they can only model
Property -Operator Value
their use is limited to certain operations, which I find myself to need not that often. And if the conditions get more complex I need to write a scriptblock anyway, having to refactor your former form into the latter.
Point being that it's easy to write a script that works fine on v3/4 but fails when run on v2, without doing something incredibly obvious like using cmdlets or modules that didn't ship with v2. Here is a by-no-means-comprehensive list of potential gotchas:
• Operation Statements vs Script Blocks
• Several new operators
• Changes to $PSScriptRoot and $MyInvocation
• Stop parsing symbol --%
• Ordered dictionaries
• New redirection operators
• Count and Length properties added to "arrays" of zero or one
• Retrieving a property from a collection that only exists in the individual items returns the value from all items.
• BadNumericConstant
I thought powershell had to be explicitly installed/enabled even in win7.
I'm not going to walk a user through that when I can do what I want in batch (with more pain, but still less than ending up providing support...).
My normal area is Linux though, and both powershell and batch make me appreciate bash so much more. Even those little things like being able to format arbitrary dates as you want...
Right, that's excruciatingly hard in PowerShell (hey, you even get Unix date format strings with Get-Date -UFormat). (But I guess we just come from different worlds here, as every time I have to read or write bash scripts it makes me appreciate PowerShell so much more.) Granted, the batch variant is ... not as pretty:
for /f "skip=1" %%x in ('wmic os get localdatetime') do if not defined MyDate set MyDate=%%x
echo Today: %MyDate:~0,4%-%MyDate:~4,2%-%MyDate:~6,2%
And I found the PowerShell script alongside with the batch file a pretty workable solution. Nicer language and still something for clueless users to double-click.
Powershell is actually a really nice shell/scripting language. I often miss its power, simplicity and not to mention the immense amount of flexibility having all of .net accessible when using a 'nix box.
That sounds like a symptom of simply being more familiar with the Windows environment. People who have grown up in China probably find chopsticks simpler and more powerful than forks -- I'm hypothesizing -- but not because forks don't work.
I wouldn't say so. I would kill for a halfway decent Ruby shell. On Windows I'd be going on about the power of .net and on nix I'd be promoting how awesome having the power of gems in my shell is. Powershell really is quite good and blows sh/bash/zsh out of the water. The "everything is an object" model instead of passing around strings really changes how you work.
I know far more about scripting linux/unix than Powershell, so I can't really speak directly to Powershell's strengths and weaknesses. But there's reason to be skeptical that Powershell has actually blown bash out of the water, I think. If it made that much difference, linux/unix would have adopted Powershell's object paradigm for itself.
I'm not sold on Ruby gems. I haven't learned Ruby yet. Shell scripting to me means bash (or /bin/sh) + whatever utilities come standard on a unix system: sed, awk, etc.
The goals may be slightly different, reflecting the different cultures using the shells. What I think is cool about bash scripting is that I use bash constantly, anyway, which makes it easy to test small script fragments before including them in a full-on script, and even though, e.g., some things are nasty to do syntactically in bash, I get lots of practice.
Often I start with a batch file, just to notice after a dozen lines that this sort of thing is much easier to write and maintain in another language. And in the last two years I shifted more to PowerShell than batch in many cases. Some of that is surely due to atrocities like Windows XP dying out and Vista never being common. For scripts that developers execute on their machines PowerShell should be a fairly safe bet in a Windows environment by now. Deployment or build scripts should probably be MSBuild or something similar.