You are browsing archives for
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.
Last week, we discovered the benefits of shell scripting, and got our first glimpse at an example script.
This week we’re going to dissect the sample script and learn about the various components that make it tick.
Bash shell scripting is a very cool concept, disguised by a very prosaic title.
The concept is that anything that goes on in the command line can go on in a shell script.
So, why would anyone want to do anything in a shell script, that they could already do in the command line?
I’m glad you asked; because I made a list. 😀
It’s official; I’m oblivious.
That is the only possible explanation, really, as to how I could have missed this.
Today I ran across a very useful and informative tidbit that would have been very useful to me back when I was first beginning to learn the Linux command line.
In an upcoming series I’m going to start exploring the basics of shell scripting (writing your own little programs that run from the command line and make things happen).
In the meantime — with not a little prompting from my Dad — I’ve decided to explore the dot slash issue.
I call it an issue, but really it’s just two keystrokes resulting in two characters that get placed before shell scripts to execute said shell scripts.