In 2006, Microsoft released Windows Powershell, a new command line shell that, via cmdlets, scripts, and executables, allow core system administration tasks to be scripted. While this functionality has been available on Unix-type systems for decades, Microsoft’s version will almost certainly, within a few years, be available on several hundred million PCs. So how does the Powershell stack up against Linux favorite bash? MSDN links to this Bash vs Powershell article.
Bash vs Powershell
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
I don’t get PowerShell. After years of hype, after a couple of studied books on PowerShell, it is still feels like a overweight, totally-incompatible and awkward way of automating/scripting things.
It can’t replace the BAT files.
For simple tasks, I prefer just built-in, established means (bash on Unix, BAT files on Windows). For more advanced things, there is always Perl/Ruby/Python.
From what I understand PowerShell more or less is intended to replace standard BAT files. Maybe you can elaborate a bit as to why it cannot replace BAT files in your view.
While I am no expert on PowerShell, I do like the idea of using introspection to preserve type information between processes connected through a pipe. In Bash you are mostly stuck to using awk to parse the text-only output of some tool, since all type info has been lost.
Does anyone know why they chose the ‘$’ like PHP syntax for variables? Does this facilitate parsing or something? The dollar sign in PHP mostly feels redundant, although the double $$ is sometimes really handy.
One of the goals of Powershell was matching the power of Unix scripting tools.
So they intentionally chose a Perl-like syntax, hence the $.
Unless you have a quote from one of the developers of powershell somewhere I’d really have to question this statement. That sounds a lot like “Oh I wanted to make a car with the power of a Porsche so I copied the horse emblem.”
The reason why a lot of early languages used variable identifiers such as the $ was because it made life so much easier from the parser point of view, especially if you are designating a difference between the variable as an object in its own right or whether you wanted the contents of the variable.
Now with regard to why powershell uses it I don’t have a good answer, its supposed to be based around the .net framework which doesn’t need those type of identifiers and to be honest it feels like if they were constructing a scripting language from scratch they would have made it syntactically comparable to more modern languages.
Early languages like FORTRAN, COBOL, LISP, etc had no such syntax.
I don’t have a specific quote but if you look at Powershell it resembles Perl in a lot of other ways.
And yes putting a Porschë emblem on a car instantly makes it much more marketable!
>It can’t replace the BAT files.
I like 4DOS: http://4dos.z-bg.com/
Me too… And 4OS2, and 4NT, and Take Command, and…
I love powershell, it is much more powerful and flexible than batch files, even with the limited branching that batch files support.
I’m well on my way to purging my servers of as many batch files as possible, replacing them with ps scripts, as it gets rid of so many 3rd party tools (like blat). Because it’s .NET based, it allows you to write directly to the eventlog, watch directories for changes, access AD, you name it.
Less 3rd party tools mean simpler environments.
I really love Microsoft Marketing. They are so impressive. They rediscover stuff, (recode also) and explain to anybody they have the best stuff around
Good job guys! Powershell only takes half a minute to launch! the command lines are soooo simple … –laughing-out-loud … it’s (as always?) not compatible with anything (because 99% of apps on windows have no command line options) It requires the almighty .Net version 3.X framework to work 😐
Well in a Vista world, I just can say that Powershell is not that bad
Edited 2008-07-08 13:47 UTC
For Windows automation, check out AutoIt:
http://www.autoitscript.com/autoit3
And its distant cousin, AutoHotKey:
http://www.autohotkey.com
The former is better for GUI automation. The later is better for scriptable, system-wide hotkeys/hotstrings.
I use them both and like them both
Stop bashing Microsoft. Hehehe
Considering BASH works on Windows and PASH (FOSS Powershell) works on *nix. Was a comparison really needed?
Edited 2008-07-08 14:21 UTC
I use bash on Windows with cygwin. Powershell is useless to me because my customers won’t upgrade to Vista anytime soon. Bash works anywhere and scripts are portable. I don’t get the point of powershell. It’s kind of a new language that nobody knows that offer no real advantage beside being installed by default on Vista. I agree it is way better than BAT (what isn’t better than BAT anyway), but why didn’t they just even try to use something sort of compatible with the rest of the world… again? Not even compatible with their own systems (older than Vista)? What are they trying to achieve really? Just install cygwin and use bash. It’s a no brainer to me.
PS runs on Windows XP/2003/Vista/2008. No need for Vista.
http://www.microsoft.com/windowsserver2008/en/us/powershell-faq.asp…
Edited 2008-07-08 14:30 UTC
> 2008
PowerShell does not work on Windows 2008 Server Core –
officialy:
http://dmitrysotnikov.wordpress.com/2008/05/15/powershell-on-server…
It works on every other version, that’s just nickpicking, really. My point was that it runs on XP and 2003, as well as Vista and 2008
Even so, why didn’t they make it somewhat compatible with other shells? I mean all shells use special features, be it ksh, bash or zsh, but they all support plain sh. For instance, GNU autotools’ configure script doesn’t use extra features and it can run everywhere *except* Windows because ps doesn’t support basic shell syntax! Did they really have to invent a new syntax for basic features to support the extra ones when others shells do not have to?
I don’t see why it had to be compatible with other shells, it doesn’t run on a *nix and a lot of the underlying toolset is missing, grep, awk you name it. Also, they had a nice new powerful framework to base it on, with all the functionality a good shell needs.
If they had of tried to make it sh compatible, you would have ended up with a system that looks compatible, but would probably fail in such subtle ways as to make it incompatible, and super annoying.
If you really want or need to run a unix cli, why not run Linux or BSD? we need good interoperability between OSs, but not cli syntax compatibility.
If your scripting language doesn’t run *everywhere* then you are wasting your time (unless you a relatively small organisation, in which case any solution would work).
Any big organisation has a lot of all kinds of environments. Plus, whatever you are running on now is not what you’ll be running on in the future, so why not future-proof yourself by choosing portable solutions. That is, something other than “fashion-of-the-day” PowerShell.
It makes better business sense to be portable unless you are a “ohh, look, shiny new features” kind-of-guy rather than someone who wants to get stuff done. Plus other (usually less talented) folks be need to be able to maintain your stuff otherwise you’ll never be able to be promoted.
“If your scripting language doesn’t run *everywhere* then you are wasting your time (unless you a relatively small organisation, in which case any solution would work).”
I gotta disagree with you there, I can learn more than one scripting language, and there’s lots of ways to move information between 2 different OSs. soap, rpc, email, ftp, sms, html, ODBC, blah blah blah. I’m more interested in capabilities and choice, not conformity.
Be a special snowflake, no one asked you to conform. That is not what was being discussed.
In fact, I wasn’t talking about what *you* or *I* might like personally. It isn’t “all about you”. I’m sure you are very capable of learning many scripting languages. The point was that if you had to pick a single scripting language that less-capable 9-to-5ers had to be trained in (as part of their job, and yes the world is full of these people, and surprisingly enough they do have to do scripting from time to time). It would also have to work everywhere since the biggest environments (banks, government ministries, the military) have all sorts of platforms (usually mainframes and proprietary Unix as it turns out). Then the rational choice is not PowerShell.
So yes, we understand that you personally like PowerShell. However, just because it works for your (possibly small-to-medium) problems doesn’t mean that works for everyone and everywhere. Other scripting languages will work everywhere, which makes them far more useful than PowerShell. Sure they don’t have the easy Windows integration that PowerShell does, but they can still get the job done (on all platforms). Do you now understand why PowerShell isn’t the number one recommendation for general use by many people, since I don’t wish to labour the point further?
No. I do not understand, as for the first time in 20 years, Windows has a properly supported, properly scriptable command line, from MS. There was no need to make it sh compatible, as if you need sh, use a *NIX. or use some other scripting language on Windows. You have that choice.
You do not have to make Windows become Linux for it to be improved. Sometimes I think people will always complain, no matter what comes along. People complain that Windows doesn’t have a proper command line, It finally gets one, and now some complain that it isn’t sh compatible. Tough. Windows is not Unix, it’s not Linux, and it ain’t OS X. If you need Unix, USE IT.
Finally, the university I work at has 15,000 students and around 3000 staff and faculty. We are not a small institution. My problems are not “small to medium” and we do not have “(possibly small-to-medium) problems”. We have a very heterogeneous environment, and I have never seen the need for such a level of compatibility, as it’s important to be able to exchange data between systems, but mostly, our *nix admins run *nix boxes, and our Windows Admins run Windows boxes, and most times, that’s the way it is at most large shops.
You don’t have Windows Admins running *nix, it’s not what they were hired to do. So your level of compatibility is not needed, and I don’t think it is much wanted either. It’s these smaller shops you talk about that have people wearing more than one hat, and then, a lot of times, those environments are more homogeneous, and so a compatible scripting environment isn’t needed.
So please, don’t labour the point any more, because it doesn’t hold up. I understand you personally don’t like powershell, but grasping at such a weak straw to find something to complain about? Not very helpful, or useful.
Point noted – but your institution is still a relative minnow. You mentioned that your university has a mixture of environments. Why create artificial silos when you don’t have to? Find common tools that will break down the barriers to make everyone’s life easier, not only your own. It is a common failing of sysadmins (and computer scientists in general) to make life more complicated than it needs to be for the sake of a few shiny features. Microsoft believe that adding new features at the expense of dividing the market will work for them in the long term. They are wrong.
Be warned now that your scripts will probably break when newer version of Windows comes out (usually subtly). It is an unfortunate consequence of Microsoft’s business model. At least it will keep you in employment as you spend your life maintaining your PowerShell scripts. Meanwhile, *sh* compatible scripts will keep working for the next few decades and we’ll get one with doing more productive things.
“Point noted – but your institution is still a relative minnow. You mentioned that your university has a mixture of environments. Why create artificial silos when you don’t have to?”
There are no isolated silos here, there are much better tools available than scripting if we need systems to communicate. The systems we deploy have specific functions to perform, scripting shouldn’t really be used as an integration tool between disparate OSs. That’s what RPC/SOAP/ODBC/SSH/SAMBA is for.
There are better tools for the job. We use scripting to do specific chores on each server, or to facilitate moving data from system to system, why build the intricate interlocking scripts between servers, those are the scripts that will break, as servers change, business needs change, and if you have all these interlocking scripts, it makes migration and management a nightmare. Native scripting on each OS gives you much better access to the underlying functionality of the OS.
On top of it, the toolset on *nix is radically different than on Windows, and I don’t like spending my time trying to make up for the differences in syntax between the native Linux version of grep and some Windows port. The Powershell gives me access to the entire power of the .NET framework, and that allows me to manage and automate things better on the Windows side. On Unix, a good bash script can’t be beat, but a sh compatible environment on Windows needs a lot of extra baggage to be useful, baggage that just is not needed. It’s all ready all there, exposed to powershell. Why reinvent the wheel?
“Be warned now that your scripts will probably break when newer version of Windows comes out (usually subtly). It is an unfortunate consequence of Microsoft’s business model.”
Uh, MS LOVES compatibility, I disagree with your statement 100%. I predict the powershell to be backwards compatible for quite a while. I would think that using scripts the way you describe would be a quicker route to breakage, as you have to 3rd party scripting environments, plus toolsets on the Windows servers. upgrade one, upgrade them all.
Indeed. These are your words.
Stop listening to marketing guff and start looking at real world examples like the deprecation of Visual Basic 6 compatibility, the half-a dozen slightly incompatible versions of the Win32 API, inability of Office to read older documents perfectly etc. Then you see for all of the claims, MS does a good but hardly perfect job (they couldn’t be perfect, it is against their business model since they need slight incompatibility to drive upgrades).
In fact, stop thinking like a sysadmin and start thing like a CTO.
“Stop listening to marketing guff and start looking at real world examples like the deprecation of Visual Basic 6 compatibility”
Yeah, seeing as VB ver 1 came out in 93, and VB stayed code compatible with that version until VB 7, 9 Years later, I’d say that argument is just nonsense, and I know, I started programming with VB 3. Standard BASIC code would run under VB, so it was even code compatible with GWBASIC and Quick BASIC.
Biggest change before .NET was VB 5 with OCX controls, but it still would use VBX controls until version 6, and it was still code compatible.
“the half-a dozen slightly incompatible versions of the Win32 API”
There are 3 versions, Win32s, that ran on Win 3.11, Win32 (Win9x) and Win32 (NT). 3 Versions, and only one is extant now. That certainly isn’t a half dozen.
“In fact, stop thinking like a sysadmin and start thing like a CTO. ”
No. I am a Sys Admin, if I started thinking like a CTO, I would suck at my job.
Powershell, is long needed on windows. once you really start playing with it to do production stuff you start to see the power of it. though just like the artical said, *nix has had most of this stuff already, whats new is two things:
* powershell can pipe/pass objects and text streams
* powershell has a security policy for script exceution, eg; you have have it setup so, only certs from your company will run.
all future, MS admin tools will be built with powershell so going forward, more and more stuff will be scriptable.
exchange 2k7, powershell use is required.
-Nex6
Edited 2008-07-08 14:46 UTC
.. and then there’s this loser here or there that says that *nix is way behind in time or that the file system architecture (everything is a file in a tree) is obsolete. Ain’t that lovely to see MS eating their own words after 30 years? Modularity? Improved (???) CLI? I guess Microsoft shills will start praising the goodness of CLIs anytime now. Who knows? Maybe anytime we”ll start to see Power-Shell recipes on the web to solve common Microsoft güindous problems instead of series of pics.
Edited 2008-07-08 15:17 UTC
if your a good windows admin, then your used to scripting things. Perl has navtive windows support. you can also use vbscript. hell even python,
the main point being, just becuase your in a windows shop does not mean your brian dead and dont script anything. the only way to effectively maintain a large number of workstations and servers is *with* scripting. i have so many scripts in a few different langages, its not even funny.
and, the other admins, and IT guys i know that work in like enviroments are like wise scriptors. tho to be fair, most of us maintian or have maintianed *nix, so we carry over practices we have learned.
-Nex6
Edited 2008-07-08 15:27 UTC
‘you’re’. It’s ‘you’re’, not ‘your’.
but more seriously, the problem with Microsoft, in this context, is Technologies, IMO.
The *nix world works to the Keep it [the implmementation/interface] Simple principal. This makes the difficulty of solving your problem pretty much linear to the complexity of the problem. Of course, the lack of ‘fluff'[typically GUIs] means that the barrier to entry is usually slightly higher with this philosophy
Windows, on the other hand, seems to subscribe to the ‘Technologies Technologies Technologies'[Developers, Deverlopers…
] philosophy. They then have to re-create new interfaces to interact with each new technology.
So the barrier to entry is lower, because you are using a customised interface that is simpler to understand than an abstraction, but the moment you try to do something that the interface makers didn’t anticipate, then you hit a brick wall. And with MS, this is usually a great big ugly 1000ft brick wall.
Maybe my perspective is skewed, I’ve just finished writing a spam filter for Exchange 2003. Anyone else thinking of doing so. Dont. Ever.
…. never said I was an english major….
I agree to a point, on Nix, systems interfaces and such tend to be very simple. like bash, its simple useable. and; allows any other shell app to work with each other. the differance between powershell, is MS wanted to also pass arround objects. and interact with dot NET. with strong security built in the “shell” intself.
now, you can not do that and; keep it very simple. there has to be some complexity in it. and powershell has a roadmap, so remoting, and all sorts of stuff is on the roadmap.
microsoft has this thing where they sometimes want to “help you out” as a developer. and that, is where the problem is sometimes.
-Nex6
what do you think DOS was all about?
But we live in a world where everything is all about visuals and emotion (tv, movies, games) and less about audio/verbal intelligence. So it is reasonable for people to assume that a CLI won’t be popular in this environment.
All Microsoft needed to do was to fix command line navigation in cmd.exe. Fixing things like the up arrow history, the tab completion and remembering history between sessions would have made cmd tolerable. If they wanted to create a new command line scripting language, well…. I guess they succeeded. But, if the didn’t fix the former, it’s not going to do anything for me.
The smartest thing they could have done would have been to just port a native nix shell to Windows and install Perl, Python and Ruby by default. That just seems like it would have been too easy.