Proper Shell Scripting on Windows Servers with Perl

  • Fact: Shell scripting is a must for any serious IT admin managing a server. From automating backups to checking logs and keeping server performance and load in check, scripting is a must.
  • Fact: Shell scripting on Windows sucks.1
  • Fact: Shell scripting on Linux and other *nix operating systems is powerful, well-documented, and quite straight-forward.

Most people take a look at these three facts, and instantly come to a conclusion.. the wrong conclusion: you can’t properly manage a Windows server because it’s inherently lacking in the shell scripting department.

But that’s not true… Because here’s another fact for you:

Perl scripts are a drop-in replacement for 99%2 of all shell scripting needs.

And another fact:

Perl (unlike PHP) runs great (awesome, in fact) on Windows.

Now with these two facts in mind, you can now make a proper conclusion: Shell scripting on Windows doesn’t have to be difficult, limiting, or in any way inferior than on Linux.

Perl is an awesome language. Between the online Perl community and the millions of Perl-scripting samples across the web, it’s quite the well-documented language and no sysadmin has an excuse not to use it. The Perl modules are an extensive array of easy-to-use pluggable scripts that you just reference and run.

Perl was created for stuff like this. It’s the language of choice for hacking quick scripts that get the job done, easily, quickly, and with little pain or effort. A Perl script made to run on Linux will likely run on Windows too, with little to no hacking necessary for most of the stuff out there.

With Perl, you can easily do things like manage (prune, grep, or sort) log files, backup and FTP or email database server dumps, schedule webserver maintenance, and more.

Shell scripting with Perl is even easier than shell scripting in Bash – simply because of the huge libraries available that make even the most mundane and PITA tasks quite easy. It takes all of 6 statements (we’re purposely refraining from counting lines because this is Perl we’re talking about) to compose an email with your MySQL dumps as a GZIP’d attachment.

You can easily schedule Perl scripts to run at regular intervals with the Task Scheduler – but that’s about all you’ll ever need to interact with Windows for.

A quick Google search will reveal millions of results for “Perl server management scripts.” Take your pick, hack it, and run.

Here’s our 5-step guide to managing your server with Perl scripts:

  1. Download and install Perl for Windows (ActivePerl, free).
  2. Read the Perl FAQs and get familiar with the syntax. It’s nothing too complicated, and very simple to code in (though reading someone else’s code is another story). You absolutely don’t need anything more than the basic syntax, stuff like classes and functions are completely unnecessary for shell scripting – it’s too easy to even be considered programming!
  3. Write your Perl script. Use a real text editor like Notepad++.
  4. Test it by running it from the command line and ensuring it does what you need. Repeat step 3 as needed.
  5. Open up Scheduled Tasks in the Control Panel and set up a new task to run your Perl script however often you like.

Sure, maybe it’s not as easy it looks and it’ll probably take you a day or so to go from absolute zero to cranking your first Perl-based shell script; but soon enough you’ll be doing it blindfolded and with both your hands behind your back. And it’ll only be one line long, too!

The most important thing to realize is, you don’t need to be a programmer (or become one) in order to shell script in Perl.

Just pretend your Perl script is a batch file (yuck!). The Perl processor will run it from top to bottom, in a very straight-forward manner. Put one task/command per-line, stick loops where needed, and test constantly. You don’t need classes, you don’t need data structures, you don’t need object orientation, and you don’t even really need to use variables if you don’t want to!

We’ll be posting more details, guides, sample shell scripts, and how-to’s on Perl-based shell scripting in the weeks and months to come. Don’t give up just because it involves learning something new, this is in an investment that’ll last a lifetime. If you can shell script in Perl on Windows, you can do the same on Linux and OS X with ease. If you can shell script in Perl, you can do anything!

View all articles in the “Shell Scripting with Perl” category.

  1. Hopefully Monad (Microsoft Power Shell) will provide a solution, but so far the results are mixed; and it’s not popular enough to be considered a viable substitute at the moment. 

  2. We admit, that’s a made up statistic, give us a break though, will ya? 

5 thoughts on “Proper Shell Scripting on Windows Servers with Perl

  1. I’m a Linux kinda guy, and never did much imagine Windows as a viable enterprise product.

    But you’re right, I’ve used Perl to create complex shell scripts on Linux multiple times, and find it to be far more productive than plain old bash scripting – so I guess this could theoretically work…

    But you’d still have to deal with the lack of the ability to pipe output from one command to the other, amongst other things… Basically, Perl will only give you a wrapper for shell scripting, so you’ll still be (in some ways) limited by Windows’ own incapabilities.

  2. I’m not going to deny that the lack of piping (amongst other things) is an obstacle – because that’s definitely true. However, command line programs on Windows don’t use piping in the first place, so whatever task you accomplish on *nix via piping can still be done on Windows, just with a different syntax.

    That’s the difference between VMS-based (seeing as NT is technically derived from that) and POSIX-based systems – the VMS model doesn’t including piping content in the first place.

    This is a *semantic* difference, and not an actual limitation, per-say.

    However, it certainly is useful to pipe output from certain tools to GREP, etc. but with Perl you can store the output in a variable and GREP it to your heart’s content.

  3. Hey this comment is not regarding this topic but I would like to tell the guys at Neosmart that their tooltip fixer is very very helpful, but it consumes around 7 MB of memory and 16 MB of virtual memory on my comp, can you rewrite it to be absolutely resource-efficient?

  4. I completely disagree that shell scripting sucks. We have Cygwin/Services for Unix on XP and Vista which can gives us bash, csh, zsh and all the *nix tools etc etc and we have the command prompt (which is not so bad) and VBScript is so simple yet powerful and PowerShell absolutely rocks! I would say Windows is technically superior in scripting, except that scripting isn’t as easy as AppleScript or Automator.

  5. Well, that’s cheating! :P

    No really, Cygwin/Interix/MinGW/etc is not shell scripting with Windows – it’s faking Unix shell scripting for a Windows Platform…

    Besides the incompatibility issues and the absolute slowness of Cygwin (though mingw performs decent), your time and effort would be better invested using the more productive Perl method, w/ all the modules available and performance benefits.

    We intentionally (and explicity) left Monad out – but I agree, it’s definitely a very big and very positive step forward… Gives me high hopes for Windows Server 2008. The future of Monad for shell scripting and server management on Windows deserves an article of its own, and I’m sure that in time (when the Monad scripts start popping up on Google for whatever task it is you’re trying to do) it’ll be the role-model for shell scripting.. but that’s a whole ‘nother story :)

Leave a Reply

Your email address will not be published. Required fields are marked *