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.
Piping and redirection are two tools that, although I have mentioned them before, I vastly under-utilize in the command line.
To that end, I have decided that a more thorough exploration is warranted, so that I might come to appreciate these tools to their fullest — and remember to use them!
In previous posts, I have touched on both paths and navigation, without going into all of the details.
Since the two are so closely intertwined, I decided today to go into greater detail about both subjects at once, with an emphasis on how to navigate via the Linux command line, and what shortcuts are available to streamline the navigation process.
In a previous post I mentioned wild cards very briefly, in conjunction with the Linux command line.
I did not stop to explain at that time, but wild cards have a life that extends far beyond the Linux command line.
It is time now to delve deeper in this subject, as it is a great one to be aware of. But take note that I will be focusing back on the use of wildcards in the Linux command line.
The premise: A beautiful Saturday, with a cool breeze, a cloudless sky, and the outdoors calling my name.
The catch: I had work to do.
The problem: I turned on my computer to start working, and could barely even see the screen.
Now, one might automatically assume that I needed glasses (I don’t), or that the bright sun was reflecting on my screen (to taunt me), but this was not the case.
If you’ve used the Linux command line much at all, you’re probably familiar with yum.
Yum — an acronym for the “Yellowdog Updater, Modified” — is an RPM-based package manager that is now obsolete.
Dnf — an acronym for “Dandified Yum” — is the replacement RPM-based package manager used in place of yum.