Scripting is a very useful skill which will save any Sysadmin a lot of time. Who wants to go to every device in their environment and perform the same task over and over again? In this posting I will cover a few basics for those getting started in scripting.
When writing a script you want to be sure it is:
Full of Comments
When you think about it; writing scripts is not all that different from developing software. You are writing a bit of code for the computer to interpret in order to complete a task. You script may or may not have anything visible on the screen, but same goes for software you may write.
The main difference between a script and a program is a script is interpreted and a program is compiled then executed. A script you can modify with a text editor, then run immediately. A program you must modify, re-compile, then re-run. You might even use the same languages when scripting vs programming. Other than this minor difference, they are really the same thing; so the same principles should apply when developing your scripts.
Lets go through our three bullet points:
When you write your script, you want to be sure that you and whoever looks at it after you can easily read it. This will aide in troubleshooting later on, or making adjustments when things change in your environment.
I could write an entire article on how to make a script readable, so I will save that for another time. In the mean time; I would suggest reviewing scripts others have written and pay attention to the way they are formatted. This will help give you an idea of what is easy to read, and what is hard to read.
So you just spent all this time writing a script, testing it, and using it to complete that task that was going to take you 2 days, but since you wrote a script, you were able to complete it in a few seconds. Wouldn’t it be great to be able to re-use some of that work next time a task comes up? Whenever you are writing a script, try to keep in mind that you might want to re-purpose it someday to accomplish a similar, but different task.
A few tips for making your script re-usable:
Use Functions/Sub-Routines: This one is my favorite. If you write a function for each task your script performs, you can simply copy that function into the next script you write to do the same thing. For example: Maybe you have a script which deletes files older than 5 days old. When you wrote this script you wrote a date compare function to tell you how many days old a given file is. Later on you write another script where you want to list all the files older than 5 days old. If you used a function in the first script, the second script will only take you a few minutes. If you didn’t use a function, you might find yourself having to re-write a good portion of the code.
Use Variables: Don’t hard code things into your script. If we use the example above where you want to write a script to delete all the files in a folder older than 5 days old, you may later on decide you want to only delete files older than 7 days old. If you hard coded the number 5 into your script, you may have to change it in 10 different places. But, if you used a variable; you simply have to change the variable, then it changes everywhere in the script.
Full of Comments:
One of the worst things is to go back and look at your script, or someone else’s script and not have a clue what is going on. And if you write your script properly, you should not have that moment. Comments in your script are very important. These can make it very easy to look at a block of code and know exactly what it does; even if you don’t know the language the script was written in. As you go about writing your script, be sure to write a command any time the task you are doing changes.
For example; we can use the same theme we started earlier in the article and say you have a script which scans a folder for files older than 5 days old, then deletes them. You might want to comment the part where you: Initialize your variables, where you setup your file system object, where you scan for the files, and where you delete your files. These are just a few ideas. Depending on your actual script; it might make sense to have more comments or fewer comments. Regardless of where you comment, the spirit is the same. You want to be able to quickly scan the script and know exactly which part does what.
Hopefully this article has been helpful to you. I have gone over a few basics to consider when you start scripting. In the future I will go more in-depth about the concepts. Be sure to check back to the site as I will be posting scripts for performing various tasks.