I am a lazy DevOps Engineer. So whenever I came across the same task more than 2 times I automate that. Although now we have many automation tools, still the first thing that hit into our mind for automation is bash or shell script. After making a lot of mistakes and messy scripts :), I am sharing my experiences for writing a good shell script which not only looks good but also it will reduce the chances of error. A minimum effort in the modification. Your program should talk in itself, so you don’t have to explain it. Reusability, Of course, I can’t write the same kind of script or program again and again. I am a firm believer in learning by doing. So let’s create a problem statement for ourselves and then try to solve it via shell scripting with best practices :). I would like to have solutions in the comment section of this blog. Problem Statement Write a shell script to install and uninstall a package(vim) depending on the arguments. The script should tell if the package is already installed. If no argument is passed it should print the help page. So without wasting time let’s start for writing an awesome shell script. Here is the list of things that should always be taken care of while writing a shell script. Lifespan of Script If your script is procedural(each subsequent steps relies on the previous step to complete), do me a favor and add in starting of the script so that the script exists on the first error. For example: set -e -e -x () {
    yum install docker
} () {
    docker images } #!/bin/bash set # Script exists on first failure set # For debugging purpose install_package list_docker_images # depends on success of install_package function Functions Ahha, Functions are my most favorite part of programming. There is a saying “ Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ” To achieve this always try to use functions and name them properly so that anyone can understand the function just by reading its name. Functions also provide the concept of reusability. It also removes the duplicating of code, how? let’s see this () { PACKAGE_NAME= yum install -y
}

install_package #!/bin/bash install_package local " " $1 " " ${PACKAGE_NAME} "vim" Command Sanity Usually, scripts call other scripts or binary. When we are dealing with commands there are chances that commands will not be available on all systems. So my suggestion is to check them before proceeding. () { PACKAGE_NAME= ! -v > /dev/null 2>&1 }

check_package #!/bin/bash check_package local " " $1 if command " " ${PACKAGE_NAME} then printf " is not installed.\n" ${PACKAGE_NAME} else printf " is already installed.\n" ${PACKAGE_NAME} fi "vim" Help Page If you guys are familiar with Linux, you have certainly noticed that every Linux command has its help page. The same thing can be true for the script as well. It would be really helpful to include flag. --help INITIAL_PARAMS= () {
    { }
} () { [ == ]; help_function }

arg_checker #!/bin/bash "$*" help_function printf "Usage:- ./script <option>\n" printf "Options:\n" printf "  -a ==> Install all base softwares\n" printf "  -r ==> Remove base softwares\n" arg_checker if " " ${INITIAL_PARAMS} "--help" then fi Logging Logging is the most critical thing for everyone whether he is a developer, sysadmin or DevOps. Debugging seems to be impossible without logs. As we know most applications generate logs for understanding that what is happening with the application, the same practice can be implemented for shell script as well. For generating logs we have a bash utility called . logger DATE=$(date) DATE () { FILENAME= ! ls > /dev/null 2>&1 logger -s logger -s }

check_file #!/bin/bash declare check_file local " " $1 if " " ${FILENAME} then " : doesn't exists" ${DATE} ${FILENAME} else " : found successfuly" ${DATE} ${FILENAME} fi "/etc/passwd" Variables I like to name my variables in Capital letters with an underscore, In this way, I will not get confused with the function name and variable name. Never give etc. as a variable name instead of that try to give a proper name to a variable as well just like functions. a,b,c GLOBAL_MESSAGE= () { LOCAL_MESSAGE= }

message_print #!/bin/bash # Use declare for declaring global variables declare "Hey, I am a global message" # Use local for declaring local variables inside the function message_print local "Hey, I am a local meesage" printf "Global Message:- \n" ${GLOBAL_MESSAGE} printf "Local Message:- \n" ${LOCAL_MESSAGE} Cases Cases are also a fascinating part of shell script. But the question is when to use this? According to me if your shell program is providing more than one functionality basis on the arguments then you should go for cases. For example:- If your shell utility provides the capability of installing and uninstalling the software. () {
    MESSAGE= } -i|--input)
        print_message ;;
    -o|--output)
        print_message ;;
    --debug)
        print_message ;;
    *)
        print_message ;; #!/bin/bash print_message " " $1 echo " " ${MESSAGE} case " " $1 in "Input Message" "Output Message" "Debug Message" "Wront Input" esac In this blog, we have covered functions, variables, the lifespan of a script, logging, help page, command sanity. I hope these topics help you in your daily life while using the shell script. If you have any feedback please let me know through comments. Cheers Till the next Time!!!!

Mind

Another Reason to Use Docker

Logging Everything in JSON Format

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

How To Create a Foolproof Shell Script

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Another Reason to Use Docker

20,000 Leagues Under Your Shell

47 Stories To Learn About Bash

A Basic Guide to MySQL Tests Automation

A Web Service Written in Pure Bash.

Another Reason to Use Docker

20,000 Leagues Under Your Shell

47 Stories To Learn About Bash

A Basic Guide to MySQL Tests Automation

A Web Service Written in Pure Bash.

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps