Scripting Best Practices


 
Thread Tools Search this Thread
Top Forums UNIX for Dummies Questions & Answers Scripting Best Practices
# 1  
Old 03-04-2005
Scripting Best Practices

Hi - I am new to this and was wondering if some of you can help me out. I am just starting to write scripts and need some guidelines on creating scripts. I'm calling them "Best Practices"...what should I do and not do when creating scripts.

All I know so far is that I should avoid putting usernames/passwords in scripts and I should avoid hard-coding a host name in a script. I would think there are a lot more of things like this, so if you could help me out, I would greatly appreciate it.

Thanks!
Todd
# 2  
Old 03-08-2005
Quote:
Originally Posted by toddjameslane
Hi - I am new to this and was wondering if some of you can help me out. I am just starting to write scripts and need some guidelines on creating scripts. I'm calling them "Best Practices"...what should I do and not do when creating scripts.

All I know so far is that I should avoid putting usernames/passwords in scripts and I should avoid hard-coding a host name in a script. I would think there are a lot more of things like this, so if you could help me out, I would greatly appreciate it.

Thanks!
Todd
Use this link for advanced scripting as,
http://www.tldp.org/LDP/abs/html/index.html

HTH.
# 3  
Old 03-08-2005
Power Scripting Best Practices

When I first had the need to write scripts, this was the first place I looked. Here's some of the things I always do:
  • Before writing any code, know exactly what it is you want your script to do and plan for the unexpected (error-handling, false user-input,etc).
  • Write clean code, use indents and use comments to explain parts of your code!!!
  • Scripting works better if you feel comfortable using shell-commands on the host-system.
  • Variables are your friends!
  • Use functions.
  • Open another terminal and try out parts of the code to see its output on screen (good for those extra spaces that screw up IF-statements).
  • In case of the above, sed is your friend.
  • More friends: awk, head, tail, wc, grep, ps, etc...
  • Apropos is your friend too.
  • Get comfortable using a text-editor like vi, if all else fails I recommend UltraEdit which is extremely handy.
  • Don't be affraid to ask someone else if you're stuck. You can find my share of stupid questions on this forum, but you know what? I just started out then. My position now? I write really really large scripts for my company and they have come to depend on them!
  • Word of caution: sometimes scripts really stress a server. Try to be there the first few times they run, just in case. Smilie
  • Use logging when needed. Create a log-function, so you don't need then ">" and ">>" to write to or append to a logfile. One typo can clear your logs. Using a log-function prevents this.
  • Many of my scripts send me email. To stop the confusion Smilie , I always print the name of the script in the mailmessage, you'll start to appreciate this!
# 4  
Old 03-10-2005
Log-function

In a private message, I was asked how the log-function worked that I described above. Since this might be helpful to other people too, I'm answering the question in public.

First of all, I use Bash, don't know if this trick works in other Shells.

Content of script:

Code:
#!/bin/bash
. lib/functions.conf # mind the SPACE between the DOT and the path/filename!!! 
logfile=scheduler.log
func_eventlog "STARTING ABG JOB"
-=script runs some more, but that's irrelevant, the example is clear=-

Content of file: lib/functions.conf which by the way is executable :

Code:
################################################
#                                              #
# Log functie                                  #
#                                              #
# Usage:                                       #
#                                              #
# func_eventlog "Dit wil ik loggen"            #
#                                              #
# Variabelen:                                  #
#                                              #
# $logfile (logfile inclusief pad)             #
#                                              #
################################################

func_eventlog()
{
	echo -e "`date` - $1" >> $logfile
}

So whenever I want something logged, I just use:

func_eventlog "Send this text to logfile"

and I never ever have to worry about accidentally overwriting my logs instead of appending to them. Smilie
# 5  
Old 03-16-2005
and ...

* keep the same form throughout for your code ... inconsistent coding styles make debugging a lot harder regardless of who's doing it ... look at the 3 "if" forms below that people use in ksh scripting --- they do the same things but debugging could be prolonged if you used all of them in the same script instead of just 1 as the patterns are different ...

Code:
form 1: 

if [ cond ]; then
    command
fi

form 2:

if [ cond ]
then
    command
fi

form 3:

[ cond ] && command

* keep the code as simple as possible and then add to it when the basic form works ... write a quick script to test out the functionality first ... if that works, put in error checking and test ... more error checking and test ... you don't want to spend hours on the "perfect" script to learn later that it doesn't really do what you want it to do

* try not to hardcode file and/or directory paths ... makes it easier to test if you could use this or that file instead of the production file or directory ... like indo says --- variables are your friends!

* test as much as possible on a non-production server that closely mirrors the production environment ... unless you want to risk losing live production data --- that could be detrimental to your employment
# 6  
Old 03-26-2005
I think all of this leads to a few words that my prof in college taught me.


Modularity...

Write code in modules/sections so that nothing is hard coded where possible and that sections of the code can be excluded/replaced/deleted and the program will still function with no other modification.

Documentation....

If your programming out lives you, the next person will need to know what the heck you were doing. reading the code can be confusing, but comments help greatly.

Use of echo...

When troubleshooting your scripts insert echo commands in loops and wherever a decision is made in a forking statement like if/then/else or while/true or in case statements..... this aids in making sure to test all your logic down every path.
 
Login or Register to Ask a Question

Previous Thread | Next Thread

7 More Discussions You Might Find Interesting

1. Linux

Virtualization best practices

Hello admins and gurus I have a controversial topic: now we are investing in a new Linux OS that will hold our Sybase database. The server will virtualized on a VMware server hosted on SAN storage. Now the question is, when we install the database engine is it better - in terms of performance -... (1 Reply)
Discussion started by: abohmeed
1 Replies

2. Solaris

Best practices

Dear all, Kinda lame question but i'd like to hear your experiences and advice. Question in short ----------------- What permission should a mount point "ideally" have - i think it's root. Ex:- /usr/app/ i'd set the app to be owned by root and within /usr/app i would create another... (1 Reply)
Discussion started by: ossupport55
1 Replies

3. Shell Programming and Scripting

Global Script Best Practices

Hey there. I am a relative rookie when it comes to Linux/Unix Administration and have been learning to adapt my meager coding skill to working with shell scripts in the 'nix realms. I have done some exhausting searches for and found plenty of information on making scripts globally available but... (2 Replies)
Discussion started by: Tenuous
2 Replies

4. UNIX for Dummies Questions & Answers

Best practices for Source control

Hi all, i am trying to incorporate source control management in my project. We have about 50 - 60 shell scripts on 3 different machines dev, stag and production, but there is no source control. All the files have to be located at specific locations on each machine for it to work I want to... (4 Replies)
Discussion started by: chvs2000
4 Replies

5. Shell Programming and Scripting

shell scripting best practices - trap command

I know there is a command called trap which can be used to capture the signals from a shell script and redirect the control to a required function (such as a cleanup). My question is - Those of you who have written lot of shell scripts - do you always write a set of trap commands to capture... (4 Replies)
Discussion started by: sagar_evc
4 Replies

6. UNIX for Advanced & Expert Users

emergency shutdown best practices.

Has anyone implemented or have suggestions on how to shutdown many remote unix/linux servers from a single script initiated from 1 server? I need this to execute in parallel as time is not on my side. Our ups is sadly underrated and will die in approximately 15 minutes. (There is not... (10 Replies)
Discussion started by: jsw371
10 Replies

7. Shell Programming and Scripting

Korn Shell Best Practices

I am new to ksh scripts (still reading manuals). I need to write an application that reads a multi-line parameter file, builds sql on-the-fly, runs plsql and saves the output in a specific format for further processing. I am looking for anything on Best Practices for building such an... (1 Reply)
Discussion started by: mtravis
1 Replies
Login or Register to Ask a Question