OpenSource.net

Bash scripting offers a practical solution to repetitive tasks.

In part four of this series, you’ll learn how to create a simple shell script and why This powerful skill lets you automate common sysadmin duties, freeing up your time for more strategic work. This guide provides a solid foundation in Bash scripting, helping you streamline your workflow and become more efficient.

Author’s note: This article is part of a series originally published on Opensource.com, combining and updating previous content for an updated learning experience.

Intro

Linux system administrators have powerful tools at their fingertips to streamline tasks. This series explores leveraging Bash shell scripting for automation, a valuable skill that will save you time and effort.
We’ll delve into:

• The advantages of automation with Bash shell scripts
• Why using shell scripts is a better choice for sysadmins than compiled languages like C or C++
• Creating a set of requirements for new scripts
• Creating simple Bash shell scripts from command-line interface (CLI) programs
• Enhancing security through using the user ID (UID) running the script
• Using logical comparison tools to provide execution flow control for command-line programs and scripts
• Using command-line options to control script functionality
• Creating Bash functions that can be called from one or more locations within a script
• Why and how to license your code as Open Source
• Creating and implementing a simple test plan

This article explores why shell scripts are a key tool and the basics of creating a very simple Bash script.

Why I automate everything

In Chapter nine of “The Linux Philosophy for Sysadmins,” I wrote:

“A sysadmin is most productive when thinking—thinking about how to solve existing problems and about how to avoid future problems; thinking about how to monitor Linux computers in order to find clues that anticipate and foreshadow those future problems; thinking about how to make [their] job more efficient; thinking about how to automate all of those tasks that need to be performed whether every day or once a year.

“Sysadmins are next most productive when creating the shell programs that automate the solutions that they have conceived while appearing to be unproductive. The more automation we have in place, the more time we have available to fix real problems when they occur and to contemplate how to automate even more than we already have.”

We’ve all sighed with relief after a long, complex command-line task. But what if you never had to worry about repeating it? Bash scripting automates these tasks, saving you time and frustration.

We all rely on memory, but it’s not perfect. Bash scripting eliminates the struggle of remembering complex tasks – you just write it down once and automate it for the future by storing it in a standard location, like /usr/local/bin or ~/bin, then I can just type the name of the shell program and let it churn out all the tasks I used to do manually.

Beyond convenience, automation saves you valuable time. Recalling complex commands and retyping them is a time sink. Bash scripts eliminate this by automating repetitive tasks, freeing you to focus on other priorities.

Shell programs

Writing shell programs—also known as scripts—is the best strategy for leveraging my time. Once I write a shell program, I can rerun it as many times as I need to. I can also update my shell scripts to compensate for changes from one release of Linux to the next, installing new hardware and software, changing what I want or need to accomplish with the script, adding new functions, removing functions that are no longer needed and fixing the not-so-rare bugs in my scripts. These kinds of changes are just part of the maintenance cycle for any type of code.

Every task performed via the keyboard in a terminal session by entering and executing shell commands can and should be automated. Sysadmins should automate everything we are asked to do or decide needs to be done. Many times, doing the automation upfront saves me time the first time.

One Bash script can contain anywhere from a few commands to many thousands. I have written Bash scripts with only one or two commands, and I have written a script with over 2,700 lines, more than half of which are comments.

Getting started

Here’s a trivial example of a shell script and how to create it. Classic programming starts with “Hello world.” This simple example translates to a single command on the command line:

$ echo "Hello world"
Hello world

By definition, a program or shell script is a sequence of instructions for the computer to execute. But typing them into the command line every time is tedious, especially when the programs are long and complex. Storing them in a file that can be executed with a single command saves time and reduces the possibility for errors to creep in.

I recommend trying the following examples as a non-root user on a test system or virtual machine (VM). Although the examples are harmless, mistakes do happen and being safe is always wise.

The first task is to create a file to contain your program. Use the touch command to create the empty file, hello, then make it executable:

$ touch hello
$ chmod 774 hello

Now, use your favorite editor to add the following line to the file:

echo "Hello world"

Save the file and run it from the command line.
You can use a separate shell session to execute the scripts in this series:

[student@testvm1 ~]$ ./hello 
Hello world!

This is the simplest Bash program you may ever create—a single statement in a file. For this exercise, your entire shell script will be built around this simple Bash statement. The function of the program is irrelevant for this purpose, and this simple statement allows you to build a program structure—a template for other programs—without being concerned about the logic of a functional purpose. You can concentrate on the basic program structure and create your template in a very simple way, and you can create and test the template itself rather than a complex functional program.

Shebang

The single statement works fine as long as you use Bash or a shell compatible with the commands used in the script. If no shell is specified in the script, the default shell will be used to execute the script commands.

The next task is to ensure that the script will run using the Bash shell, even if another shell is the default. This is accomplished with the shebang line. Shebang is the geeky way to describe the #! characters that explicitly specify which shell to use when running the script. In this case, that is Bash, but it could be any other shell. If the specified shell is not installed, the script will not run.

Add the shebang line as the first line of the script, so now it looks like this:

#!/usr/bin/bash
echo "Hello world!"

Run the script again—you should see no difference in the result. If you have other shells installed (such as ksh, csh, tcsh, zsh, etc.), start one and run the script again.

Scripts vs. compiled programs

When writing programs to automate—well, everything—sysadmins should always use shell scripts. Because shell scripts are stored in ASCII text format, they can be viewed and modified by humans just as easily as they can by computers. You can examine a shell program and see exactly what it does and whether there are any obvious errors in the syntax or logic. This is a powerful example of what it means to be open.

Some developers dismiss shell scripting as “lesser” programming because it’s interpreted, not compiled. But this distinction ignores the power of shell scripts for automating tasks. Both languages achieve the same goal: instructing computers to perform specific actions.

I’ve used many languages, including BASIC, C, C++, Pascal, Perl, Tcl/Expect, REXX (and some of its variations, including Object REXX), many shell languages (including Korn, csh and Bash), and even some assembly language. Every computer language ever devised has had one purpose: to allow humans to tell computers what to do. When you write a program, regardless of the language you choose, you’re giving the computer instructions to perform specific tasks in a specific sequence.

Scripts can be written and tested far more quickly than compiled languages. Programs usually must be written quickly to meet time constraints imposed by circumstances or the pointy-haired boss. Shell scripts are a sysadmin’s toolbox for quick fixes. They can resolve problems, automate cleanup tasks, and deliver programs faster than compiled languages allow. This makes them ideal for urgent situations or repetitive actions.

Writing a program quickly requires shell programming because it enables a quick response to the needs of the customer—whether that is you or someone else. If there are problems with the logic or bugs in the code, they can be corrected and retested almost immediately. If the original set of requirements is flawed or incomplete, shell scripts can be altered very quickly to meet the new requirements. In general, the need for speed of development in the sysadmin’s job overrides the need to make the program run as fast as possible or to use as little as possible in the way of system resources like RAM.

Most things sysadmins do take longer to figure out how to do than to execute. Thus, it might seem counterproductive to create shell scripts for everything you do. It takes some time to write the scripts and make them into tools that produce reproducible results and can be used as many times as necessary. The time savings come every time you can run the script without having to figure out (again) how to do the task.

Final thoughts

This article didn’t get very far with creating a shell script, but it did create a very small one. It also explored the reasons for creating shell scripts and why they are the most efficient option for the system administrator rather than compiled programs.

In the next article, you’ll begin to create a Bash script template that can be used as a starting point for other Bash scripts. The template will ultimately contain a Help facility, a GNU licensing statement, several simple functions and some logic to deal with those options, as well as others that might be needed for the scripts that will be based on this template.