This bash shell scripting series has been intended as a comprehensive introduction to shell scripting, but is lacking many details that are essential to shell script mastery.
Continuing on, you could research topics such as STDIN, command substitution, substitution operators, pattern matching, etc.
I recommend Mastering Unix Shell Scripting and Beginning the Linux Command Line to learn more about shell scripting.
I also recommend Shell Check to help weed out any bugs (or unwanted features) in your shell scripts.
In the meantime, I threw together a little cheat sheet that includes most of the points that we have covered, as a quick-reference guide.
The cheat sheet is available exclusively to my mailing list subscribers.
Now, please excuse me while I go write a script to automate my backup process.
I personally believe that there are as many ways to write a shell script as there are people writing shell scripts.
Each individual, even if they follow similar thought processes, will apply themselves to the task with various levels of knowledge, efficiency, and dedication.
One thing I think that all coders have in common, is the tendency to re-use their code — especially after they learn to write it well, and are not constantly improving it.
There is one means of re-using code that is essential to learn, as it can enable a single block of code to be called up for use multiple times within a script.
Functions — specifically user-defined functions — are the means by which blocks of code can be re-used within a script.
One of the earliest programming challenges that I was presented with was very simple: add all the numbers from one to fifty.
The problem that I had with this challenge was also very simple; I wasn’t allowed to use a calculator, or paper, or even to solve it in my head.
I was supposed to write a program that did the math for me.
At that time — I was thirteen, and seemingly clueless about logic — it seemed insurmountable. I eventually gave up.
Two years later I tried again, and that time I had a Eureka! moment when I learned about loops. Suddenly I wondered why it had ever even sounded hard. Ah, hindsight!
The if statement can be game-changing in a shell script’s logic process, but it is not the only option, and therefore not the ideal solution in every instance.
It is possible, for example, to use the if-elif-else-fi process to evaluate the value of a variable, and perform different actions based on its value, but there is a more clean-cut solution.
The case statement — or switch statement — is that solution.
One thing that you will probably realize early on when planning out a shell script, is that you cannot possibly anticipate every single outcome.
The best that you can do is plan for the outcomes and possibilities that you can anticipate, and funnel the remainders into a catch-all.
This is made possible by the most common control structure: the if statement.
I like to think of programming (scripting) as a series of decisions made based on a system of reasoning — a process otherwise known as logic.
Logic is something that we all make use of every day when we decide what to do, and how and in what order to do it. In such cases, logic is usually an unconscious process based on actions and consequences.
We employ more conscious forms of logic when solving problems and deliberately working through processes to achieve a desired result.
Programming (scripting) employs a very deliberate form of logic, brought to pass through the use of control structures, which are dependent on various conditions presented to them.
In life and programming alike, results can be controlled by whether or not conditions are met, and how and to what degree they are met. But I gotta tell you, it’s a lot easier to anticipate and control conditions in a program than it is in real life!
In order to handle shell script arguments, it is needful to know that the arguments are required.
It can be a big hassle for people running the script to figure out what exactly is required to be able to run it.
In fact, in many cases — such as those where the user does not know how to write and thus read the bash script code — using a script correctly can be just about impossible.
To solve this problem, there is a little something called user input, which allows a script to be written in such a way as to prompt the user for input, wait until it is received, and carry on with execution.
When this solution is in use, any further issues usually boil down to PEBCAK*.
Arguments bring up thoughts of heated exchanges, differences of opinion, and persuasive reasoning — unless you’re a programmer.
A programmer knows that an argument is actually a value or data that is passed to a function or a program when it is called.
In fact, if you’ve even so much as used the command line, and typed in various commands, you have no doubt used arguments with those commands already.
In bash shell scripts, arguments can be added to the command line when a script is executed, and those arguments can be read/accessed within the script.
Special variables are used in shell scripts to access command line arguments, so to begin with, let’s take a look at the special variables available.
Now that we have successfully created and executed a shell script, it’s time to start building on the functionality available to shell scripts.
The topics to come may sound heavy, but they’re actually very cool, and can serve as a basic primer for anyone interested in learning programming.
For anyone not interested in programming, the logic that can be applied in shell scripting is none-the-less a useful skill to have.
The first of these, that I found downright enthralling (when I first began programming years ago), are variables.
At long last we have reached the third part in the bash shell scripting series, and can tackle the greatest achievement of all; execution of the script.
In order to execute a script, you have to have a script file to execute, so let’s start with a few words on the topic of creating that file.