| Starting Out
|
Tip : Take a shell or Perl programming course. Getting some formal instruction will help fit things into a coherent framework. And you generally learn something you wouldn't have stumbled on yourself.
Caveat : Taking a class is no substitute for rolling up your sleeves and writing scripts. The experience you get programming is the best teacher.
|
| Your First Scripts
|
Tip : Borrow, borrow, borrow! By far, the easiest way to scale the learning curve is to look at how others have tried to solve the same problem. Don't spend precious time reinventing the wheel!
If you use a script pretty much in its entirety, programming etiquette requires that you give attribution to the original author. If a program is copyrighted, respect the use conditions of the author.
Caveat : It is great to borrow from others. However, if you don't understand what a borrowed script does, do not run it on your system!
|
| Naming Scripts
|
Tip : Make the name of a script descriptive of what that script will do. Some programmers include the suffix .sh for shell scripts and .pl for Perl scripts.
Caveat : Be careful not to use the name of a Unix shell command. Examples are test and script, which are already existing shell commands.
|
| Which Shell to Use?
|
Tip : Try to standardize on one shell, especially when starting out. That way you won't have to learn multiple shell syntax.
Caveat : When borrowing code from other programmer's scripts, be aware of the shell they are using.
|
| Pathnames
|
Tip : It is good practice to use absolute path names for the commands within a script.
Caveat : There is always an exception: don't use an absolute pathname for the cd command!
|
| Debugging
|
Tip : Test, test, test! Test early. Test often. Test (debug) as you go along.
Caveat : Be sure to test with the same shell that will interpret the script.
|
| Email aliases and forwarding
|
Tip : Don't hard-code email addresses in your scripts. Create email aliases in the /etc/mail/aliases file, and use the aliases in your scripts. Then when an email recipient has to be changed, you only have to edit one file.
Caveat : If you forward email between user accounts, be careful to avoid an infinite loop.
|
| A home for your scripts
|
Tip : Recommendation - create a directory, /usr/local/scripts and put your scripts there.
Caveat : For security, root should own your script directory and only root should have write privileges on the directory and on any scripts that are owned or run by root.
|
| Text editors
|
Tip : Recommendation - use vi.
Caveat : Whenever you start recommending editors, be prepared for a fight.
|
| Crontabs
|
Tip : If a script will run as a cronjob, only give it to root if it requires root's privileges.
Caveat : Don't forget about those other crontabs when it comes time (e.g. upgrades) to turn your cronjobs off.
|
| Voyager Upgrades
|
Tip : Prior to a Voyager upgrade, turn off (by commenting out in the crontabs) all your Voyager-related cronjobs.
Caveat : After a Voyager upgrade, review your scripts before running them again. The upgrade can potentially change many things: pathnames, patron SIF's, options to Voyager batch jobs, etc.
|
