Search

Top 60 Oracle Blogs

Recent comments

Linux Scripting, Part II

In Part I, we started with some scripting basics, as in, how to write a script. This included the concepts of breaking a script into sections, (introduction, body and conclusion)

For Part II, we’ll start with the BASH script “introduction”.

The introduction in a BASH script should begin the same in all scripts.

  1. Set the shell to be used for the script
  2. Set the response to failure on any steps, (exit or ignore)
  3. Add in a step for testing, but comment out or remove when in production

For our scripts, we’ll keep to the BASH format that is used by the template scripts, ensuring a repeatable and easy to identify introduction.

/bin/bash
set -euo pipefail
# set -eox pipefail #-x for testing
IFS=$'\n\t'

In the next section, we’ll set up dynamic argument requirements. By using this format, we create a very dynamic experience for the person executing the script. You can pass in values as part of the argument, but this way, you ask a question, offer examples or values in feedback to the person executing the script and they can offer a clear answer to the question. The answers are then used to dynamically populate values farther into the commands being executed.

To do this, we first set up the required number of arguments and arguments for our script. Our script example we’ll use, deploys a full, end-to-end solution in Azure.

usage() { echo "Usage: $0  -g  -p  -h  -l  -d  -b " 1>&2; exit 1; }
 declare groupname=""
 declare password=""
 declare holname=""
 declare zone=""
 declare data=""
 declare brcksize=""

Once we set up the required number of arguments that will need to be passed, (otherwise, the script exits.) We then set our declarations for each of the arguments to satisfy the script starting out.

Initialize parameters specified from command line

while getopts ":g:p:h:l:d:b:" arg; do
        case "${arg}" in

                g)
                        groupname=${OPTARG}
                        ;;
                p)
                        password=${OPTARG}
                        ;;
                h)
                        holname=${OPTARG}
                        ;;
                l)
                        zone=${OPTARG}
                        ;;
                d)
                        data=${OPTARG}
                        ;;
                b)
                        brcksize=${OPTARG}
                        ;;
                esac
done
shift $((OPTIND-1))

In the above section, we get the existing options, (a blank) for each of the values and then let the script know we will be providing updated values.

Passing in Values

We then let the script know we are done setting the variables we’ll be working with in the next section.

For each of the above sections, I then choose to interact with the person executing the script and ask questions to fulfill the values.  I don’t expect them to know what to enter, so this way, I can offer insight into the values they’ll want to enter.  Let’s dig into the first two entries so you can see an example of how this will be scripted:

if [[ -z “$groupname”]]; then
echo “What is the name for the resource group to create the deployment in? Example: EDU_Group”
echo “Enter your Resource group name:”
read groupname
{{ “${groupname:$}”]]
fi

if [[-z “$password”]]; then
echo “Your database login will be sqladmin and you’ll need a password for this login.”
echo “Passwords must meet reMicrosoft requirements, including caps, special characters. Example: SQLAdm1nt3stng!”
echo “Enter the login password:”
read password
[[“${password:?}”]]
fi

In the above sections, you’ll note that we start with an IF statement, stepping through each of the variables,  making a statements and asking questions using a simple ECHO command and then prompting for the value, reading the value and then exiting from the IF statement.

For the first example, groupname, the user will see the following on their screen:

What is the name for the resource group to create the deployment in? Example: EDU_Group

Enter your Resource group name.

Then the user will be prompted for their value to enter.  This makes the experience much easier on the person interacting with them script, providing more value.  

Notice in the next example, for password, I’ve not only stated that password requirements for the SQL Database password must be met, I’ve added an example for the password, too.  Passwords can easily be hardened after the hands on lab, so it makes sense to make this as easy as possible or set up for success for someone working with your script.  I’ve built a second script that hardens the environment anyway.  Always script like a five year old is going to be the one executing the script and think ahead with additional enhancements as you go along.

I’ll let you absorb this and we’ll move onto the next step soon!

 



Tags:  ,


Del.icio.us



Facebook

TweetThis

Digg

StumbleUpon




Copyright ©  [Linux Scripting, Part II], All Right Reserved. 2019.