Automating Standard Script Generation
Some thoughts on Automating and standardizing how you might create new scripts (or other) tools
Seasoned Unix/Linux administrators will usually have some level of experience with automating various aspects of their duties including: backups, deployments, monitoring, code management, system config management, build management, etc. A number of us will also have simple tools that we use to ease the creation of new tools for new projects (as well adding to or enhancing the previously listed systems items.)
After a recent project a client asked, “What tool(s) did you use to generate all this report data?” Of course I replied that I wrote custom tools using standard utilities available with the OS distribution. When working on consulting projects I usually tote my simple arsenal along but my base tool is simply called, “new.script“. While there are many scripting languages not all of them are standard across Unix/Linux distributions; in addition, many such ‘enhanced’ tools may require additional libraries, modules, etc. which, in many cases will NOT be available for various reasons. For general, multi-OS use I prefer to create simpler tools using standard/common system utilities that are OS portable and simple to customize.
The new.script tool does a number of things for me:
- provides a standard set of ‘features’ (built-in variables that I commonly use, a built-in edit argument, etc.)
- utilizes previous tools and methods
- uses it’s own ‘path’ to determine where the new script will live
- aborts if the ‘new script’ already exists
- makes it quick and simple to create any new tool
- once the script creates the ‘shell’ for the new tool then my editor is called and I can proceed with adding the meat to the new tool
So what happens after you create the new script? When you run it the new script will:
- Set the variable CMD to the name of the script
- When the first argument = “edit” then – if script.edit exists then use that to edit this tool (script.edit includes backup, code repository options); if script.edit does not exist then open the tool with ‘vi’.
- Set the location of BIN_DIR to the location (path) of the script
- Set ‘traps’ that call the function catch_trap (which emails you when things go poorly)
- Sets up a location and log file name for use if you need logging for this tool
- Sets up ‘shortname’ for this script (useful for logging and/or screen messages)
The preceding items are all examples of things you could include in your tool. I sometimes include reminders about how to accomplish certain, infrequently used tasks, i.e. in this case there is a math example. Note – I include paths for two ‘shells’ in case I need/want to change the shell.
Example generated by running: new.script test.script on my system:
#!/usr/local/bin/ksh #!/bin/bash ## test.script | Sun Nov 15 12:55:50 EST 2009 ## Skel gen by Dale Reagandale(Somewhere.)ga-usa(dot)net # create new script with base functions - dr 3/2007 # CMD=$0 if [[ "$1" = "edit" ]] then SCRIPT_EDIT=$(which script.edit) if [[ "${SCRIPT_EDIT}" = "" || "$2" = "no" ]] then vi ${CMD} else script.edit ${CMD} fi exit 0 fi ### BIN_DIR=$(dirname ${CMD}) ### ############### # add any cleanup processess here function catch_trap { echo "${CMD} terminated: $(date)" | \ mail -s "${CMD} - signal trap" ${MAIL_USER} ### remove tmp files? stop background processes? } ### ### set destination email an enable trap operations MAIL_USER="dale" ## i.e. abc@abc.net trap catch_trap 1 2 3 4 5 6 7 8 9 10 11 if [[ ${DR_LOG_DIR} = "" ]] then LOG_DIR=/tmp else LOG_DIR=${DR_LOG_DIR} if [[ ! -d ${LOG_DIR} ]] then mkdir -p ${LOG_DIR} fi fi SCMD=$(basename ${CMD}) LOG=${LOG_DIR}/${SCMD}.log ### ### ######## end of new script header ############ ############### ## LEN2=${#VAR2} # find the length of a string ## NUM=$((a+b*c)) # how to do math ############### add meat below...
I use new.script to extract the skeleton for my new script (i.e. I automate cutting out sections of the script which are added to the new script.) Another approach, and perhaps a better one for use on dedicated systems would be to create your own skeleton script and simply copy your ‘base skeleton’ into your new script. For example I could simplify new.script to something like:
#!/bin/bash
###
function new_script {
cat << EOM
#!/bin/bash
#####################################
## ${NEW_SCRIPT_NAME} | $(date)
## author: ${USER}
##
#####################################
$(cat ${SKELETON})
#####################################
## your commands start below
#####################################
EOM
}
###
#set -x
CMD="$0"
BIN_DIR=$(dirname ${CMD})
NEW_SCRIPT_NAME="$1"
if [[ "${NEW_SCRIPT_NAME}" = "" ]] ; then echo "Usage: ${CMD} NAME_of_NEW_Script" ; exit 1 ; fi
TARGET=${BIN_DIR}/${NEW_SCRIPT_NAME}
if [[ -e ${TARGET} ]] ; then echo "Exit: already exists..." ; exit 2 ; fi
#SKELETON=/path_to_your_script_base_skeleton
SKELETON=${BIN_DIR}/skel.script
if [[ ! -e ${SKELETON} ]] ; then echo "Exit: missing ${SKELETON}..." ; exit 3; fi
new_script > ${TARGET}
chmod 755 ${TARGET}
ls -l ${TARGET}
If you run the script above the only output will be from the last line. The example script above will EXIT with errors if:
- you don’t supply a name for your new script
- if the new script already exists
- you don’t have a skel.script file to copy from
Summary:
- create your own ‘skelton’ using your preferred scripting language (Perl, Bash, Zsh, Ksh, Ruby, etc…) that contains your frequently used/needed options
- create your own, customized new.script tool (again, in your language of choice) to ease the creation of new tools
- create your own standards for locating non-system tools and logs; include those standards in your tool creation process and life will hopefully be simpler…
#!/bin/bash
## test.script | Sun Nov 15 12:55:50 EST 2009
## Skel gen by Dale Reagan
dale@ga-usa.net# create new script with base functions - dr 3/2007
#
CMD=$0
if [[ "$1" = "edit" ]]
then
SCRIPT_EDIT=$(which script.edit)
if [[ "${SCRIPT_EDIT}" = "" || "$2" = "no" ]]
then
vi ${CMD}
else
script.edit ${CMD}
fi
exit 0
fi
###
BIN_DIR=$(dirname ${CMD})
###
###############
# add any cleanup processess here
function catch_trap {
echo “${CMD} terminated: $(date)” | \
mail -s “${CMD} – signal trap” ${MAIL_USER}
### remove tmp files? stop background processes?
}
### ### set destination email an enable trap operations
MAIL_USER=”dale” ## i.e. abc@abc.net
trap catch_trap 1 2 3 4 5 6 7 8 9 10 11
if [[ ${DR_LOG_DIR} = "" ]]
then
LOG_DIR=/tmp
else
LOG_DIR=${DR_LOG_DIR}
if [[ ! -d ${LOG_DIR} ]]
then
mkdir -p ${LOG_DIR}
fi
fi
SCMD=$(basename ${CMD})
LOG=${LOG_DIR}/${SCMD}.log
### ###
######## end of new script header ############
###############
## LEN2=${#VAR2} # find the length of a string
## NUM=$((a+b*c)) # how to do math
############### add meat below…
Related posts:
- Virtual Box & Cobbler – automating virtual system builds Cobbler - a provisioning system for Linux or other OS...
- From Bash to Ruby – part 1 Bash - Changing from a proven, ubiquitous tool to a...
- Linux Bash scripting 101 (part a) There are a number of choices for the user shell...
- Migrating Static HTML pages to WordPress CMS I previously posted about migrating static pages to Drupal –...
- Rails – where is the missing stuff? ROR (Ruby on Rails) is advertised as a data-centric development...
