1

I wasn't quite sure whether this would be better on StackOverflow or not, feel free to move it if you think it's more appropriate there.

Anyway on to the question...

The Situation
We currently have a mish-mash of VBScript, DOS batch files and a handful of PowerShell scripts performing various tasks within the business.

The tasks range from figuring out who is logged on to a particular machine by IP to fairly complex text processing and database queries (SQL Server 2005/2008)

VbScript is really not a great language although it does have pretty good debugging support, PowerShell is much better but the (free) debugging support is pretty rudimentary and the less said about batch files the better

The Question
Without wanting to start a flame war (objective comments only please!) I'd like to standardise on a single scripting language, the requirements are :-

  • Must play well with Windows
  • Good debugging support (something as good as Visual Studio or Eclipse would be perfect, I'd settle for something as good as the current VBScript debugger)
  • Good exception management
  • Good memory management (Garbage Collection)
  • Good support for connecting to databases (SQL Server)
  • COM support would be an advantage
  • Preferably a light (or no) install so we can put it on servers without breaking anything
  • Performance isn't key, these are mostly overnight jobs
  • Easy(ish) to learn for a company mainly used to C#/Java/VBScript/VBA

I'd be very interested in your thoughts/recomendations

1
  • I think you're right, I've changed it Dec 2, 2009 at 18:54

6 Answers 6

6

PowerShell 2, without any doubts. I reckon it fulfils all your requirements, and its Integrated Scripting Environment does syntax highlighting and has nice debugging support, including breakpoints and step-by-step execution.

1
  • @downvoter: A comments is due when you downvote; it helps others learn what's wrong with their answers. :-)
    – CesarGon
    Dec 4, 2009 at 3:47
2

unless you're looking for wmi and dotnet specifics, I have found python to be an excellent scripting tool for all platforms. it does cover almost all of your requirements

otherwise, I suppose powershell is the way to go, although it does require the dotnet framework to be installed.

6
  • 1
    The .NET Framework is an integral part of any Windows OS since 2006.
    – CesarGon
    Dec 2, 2009 at 19:42
  • Have you tried to use PS on 2008 core?
    – dyasny
    Dec 3, 2009 at 9:47
  • I know what you mean. :-) But davidhayes' requirements didn't mention 2008 Core.
    – CesarGon
    Dec 4, 2009 at 3:49
  • well, as I said - PS2 is quite alright. but I personally prefer portable scripting, and python as a language is probably the easiest thing since ABC :) took me (a non programming type) about two weeks to start writing production scripts.
    – dyasny
    Dec 4, 2009 at 8:19
  • And 2008 R2 Core supports PowerShell. Dec 8, 2009 at 21:10
1

I don't like the ISE, but I'm spoiled with the Visual Studio IDE for other development. Some people like the free PowerGUI replacement: http://www.powergui.org. It appears to have Intellisense-like functionality.

The only objection I can think of for PowerShell is it requires the framework, and requires the 3.5 framework for some V2 advanced features. Not exactly a light-weight component if you need to deploy it to hundreds or thousands of machines.

1

As a large factor in the answer, I would ask which scripting language is easiest to deploy into your environment. Consider the following scripting languages and an all-Windows infrastructure:

  • CMD (batchfiles): Already deployed to all systems, because builtin to Windows since forever.
  • vbscript: Already deployed to all systems, because builtin to Windows since Win98.
  • PowerShell: Builtin to Windows 2008R2, Windows 7, and anything with Exchange 2007 running on it. Must be deployed to all other systems where you expect scripts to run - but not to systems you will query from scripts running elsewhere. EG Powershell can run on a Win7 system named hostA, and query properties of hostB running Windows XP which does not have Powershell installed.
  • Perl: must be deployed to all systems where scripts will run.
  • Python: must be deployed to all systems where scripts will run.

So, unless I wanted to deal with deploying one of the latter scripting engines to all of my systems, I would standardize on VBscript and/or CMD. Of the two, vbscript is far more powerful, though as an old batch scripter, I still have a weakness for CMD. When it can do the job, it usually requires far less typing! But if I had to choose, it would be vbscript for the readability and flexibility. vbscript IDE's such as PrimalScript are just a Google away.

If I had the luxury of building out a completely new environment where all systems ran Win2008R2 and Win7, I would standardize on PowerShell.

0

We have been using VBScript for years, and only recently started to look into PowerShell(V2). VBScript has its shortcomings, but it has served us well, so I don't see a reason to abandon our past investments in it. On the other hand, PowerShell is ment to be the Windows scripting language standard and the support will surely get better. So, for us it is going to be a mixed scripting environment for us for the next couple of years.

BTW, when I look at your requirement list, PowerShell easily fulfils all except the one about the debugging support and the one about exception management (but VBScript error handling is not great either). Also, one big advantage of PowerShell over VBScript is its access to .Net Framework.

1
  • 1
    PowerShell 2 has debugging support on the ISE, including breakpoints and step-by-step execution.
    – CesarGon
    Dec 2, 2009 at 19:39
0

I'd use Visual C# 2005 or 2008 Express. It meets all of your requirements, the Express versions of Visual Studio are free (as in beer), the .NET Framework (especially if you select 2005) is likely already on your servers, and it lets you tap into some of your existing development skills for some really fancy stuff.

Of course it's not really "scripting" as such, but I personally think the (optional) addition of GUI elements can be advantageous for other tasks.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .