How to Not Suck at Scripting, Part 1

I hear this ALL OF THE TIME from IT guys who have somehow not caught the script-writing bug: "I wish I knew how to write scripts". Usually it's followed by a deep breath, a sigh, and staring off either up into the ether, or down at the ground.  I'm here to tell you how you can find that bug, and make it bite you in the ass. This is Part 1 of a 2-part article.  This part will focus on the "why" aspects.  Part 2 will focus on the "what" and "how" aspects.

The Basic Basics

First off, before I get into the enumerated list, I have to explain what is this thing we call "script-writing" or "scripting".  A "program" or "application" generally implies, or denotes, program code that has been compiled into a new binary file that can be executed by the operating system, or by another (aka "host") application.  A "script", on the other hand, is generally *not* compiled into a new (i.e. binary, hex, octal, whatever) file, but left "as-is" in the original "source code".

Source Code is the stuff you type with your own sweaty, trembling Red Bull-infused hands.  If you use something like Windows Notepad to open a program file, and you can actually spot words or phrases in your native language (e.g. English, German, etc.) it's probably either source code or script code.  If you open it in Notepad and it looks like the following crap, it's probably compiled code.

MZ
(*&(#*$)@&)#($*@&#$*&^(000011100-11)!00*!&^0010010101100011100(*&@#][}{}\?<>??::^!@~&^%&^0111011010101001]]]

The simplest giveaway is the file name extension.  I'm not going to back to 101 level stuff here, but you should have a clue that .EXE files are programs or applications, while .BAT, .VBS, .JS, .PS1 and .PY are usually script files.

One important thing to remember is that while there are many scripting languages, they are all basically serving a common purpose:  providing a low-cost, low-complication resource for system admins to automate tedious or repetitive tasks.  Sure, some languages offer more robust features for certain tasks than others, but in the end, it's a matter of matching up the tools for the jobs.

This discussion dovetails a bit with my recent post titled "Why Every SysAdmin Should Learn to Write a Script", however, this one will go in the direction of establishing a few basic technical ground rules.  Stay tuned for more... :)