You are browsing archives for
While learning of all the useful commands on the Linux command line, it can be difficult to remember how much fun the command line can really be.
There are several commands whose sole purpose is to entertain, and these are the topic of the day.
The first two commands are not so much “fun” as they are useful and interesting… and there I go already.
There are some fun ones coming up — I promise!
This year had been — much to my brother’s chagrin — very Linux command-line-intensive, at least on the blog front.
The good news — if you’re not Linux-oriented — is that I’m winding down to move on to (mostly) other topics.
The bad news — because of course there had to be some! — is that this week and the next are still focused on Linux.
(If you’re my brother, you don’t have to read this!)
If you’re not my brother, can I interest you in a Linux command line cheat sheet?
Bandwidth is a prized commodity — and generally in short supply — in my household.
Due to this preciousness of bandwidth, the question of “where does it all go?” soon arises.
With that question in mind, I have spent time in the past experimenting with various means of monitoring bandwidth, to see how much I actually use on my PC.
My research resulted in several promising candidates.
Systemd is a system and service manager for Linux.
It initializes and manages/maintains/tracks system services.
Systemd is the first process started by the Linux kernel during boot-up, and as such has a process id (PID) of 1.
Systemd then starts the required daemons, processes and services that are required to make the system work.
Systemd targets determine which daemons, processes and services are started, and so targets are as good a place to begin as any other.
I’ve read books and watched tutorials on the subject of Linux, that start right out with runlevels, do a good job of explaining the init feature, and manage to loose me in a state of confusion and despair.
What I did learn, very early on, was that I could use Linux and get along just fine without understanding runlevels at all, thank you very much.
At the same time, there was always a little voice at the back of my head, telling me that unless I understood what appears to be one of the most fundamental principles of the operating system that I’m trying to learn, then why I am bothering to try?
Guess what? I looked into runlevels, and on one level — pun intended — I now understand them. Now I can continue to live, with runlevels functioning quietly in the background, without giving them a second thought.
If anyone else is in the same boat as I once was, read on. You might just learn enough to be able to appreciate their quiet efficiency.
Cron is a software utility that schedules jobs to be run, or automates tasks in the background.
Each job can be scheduled to run periodically (at specific intervals ranging from once every minute to once every year).
The cron utility is a great asset on a server that runs 24/7, when used to perform scheduled maintenance, etc.
On a PC, the cron utility can also be useful, but I personally think that it’s pranking potential is unparalleled.
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.