Exit codes answer the question above – How did it go? That is, exit codes tell you if the shell script finished successfully or has it encountered some problems and it didn’t finish successfully.
Exit code is stored in a special variable $?. Let’s look at that variable:
mislav@mislavovo-racunalo:~/Linux_folder$ ls allla
ls: cannot access 'allla': No such file or directory
mislav@mislavovo-racunalo:~/Linux_folder$ echo $?
2
If a command executes successfully, its exit code is 0. Anything other than 0 indicates a failure of some sort. To find out what exactly went wrong, you can look at EXIT VALUE or DIAGNOSTICS section in the man pages of the command that failed. (Ward, 2014)
I just wanted to leave a post saying that we will be using variables in shell scripts. We talked about variables and how they are essentially a named object that stores value in a piece of computer memory. We are going to be using them in our shell scripts for that exact purpose – storing values and then doing something based on the values of the variables.
Today, let’s talk about special variables. Special variables are contained within every shell script and can be useful, depending on what you are doing. It pays to know them.
The first type of special variables we will cover are individual arguments to the shell script. (Ward, 2014) Let’s open up our tutorialScript.sh and write (after the shebang):
echo $1
So our entire script looks like:
#!/bin/bash
echo $1
Make sure to save the script. Now, let us run our script by typing:
We see we get argument1. Try putting echo $2 instead of echo $1 and then pass two arguments to your script. If the second argument is argument2, you will get argument2 printed out. Try it out! No, really, try it out – it will take less than 1 minute of your time and it will solidify the concept, so it is a worthwhile investment based on time investment / gain ratio.
Here is a list of special variables you should try echoing out as well:
$# – number of arguments
$@ – all arguments
$0 – script name
$$ – process ID (of the shell running the script)
$? – exit code (will be covered later)
You can also shift arguments with the shift command, but I leave you to Google that if you ever need it.
Hope you learned something useful!
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 253-255
Today let’s talk about quoting and string literals.
First, let’s take a trip back down the memory lane and look at what happens when you press Enter and thus signal the shell to run a command: (Ward, 2014)
Before running the command, the shell performs substitutions on variables and globs
The shell passes the results of the substitutions to the command
Let’s remember what happens here: In the first command, echo A*, A* gets printed out because there is not folder starting with capital a. Then, for echo a*, we get anaconda3, because there is a folder starting with zero or more lowercase a’s – that is anaconda3. Same for Calibre Library, only it starts with capital c.
But get this now:
mislav@mislavovo-racunalo:~$ echo "a*"
a*
So double quotes prevent globbing. However, double quotes don’t prevent variables from expanding:
Single quotes prevent both globbing and variables from expanding:
mislav@mislavovo-racunalo:~$ echo 'a*'
a*
mislav@mislavovo-racunalo:~$ echo '$PATH'
$PATH
So thus I propose a rule-of-thumb: In shell scripts, always use single quotes unless you have a strong reason not to do so. This is to prevent unintended globbing or variable expansion.
A sidenote: If you ever find yourself in a situation where you need to escape single quotes within a single-quoted string, see (“How to escape single quotes within single quoted strings,” n.d.).
We haven’t added anything to our tutorial script. I will tell you explicitly when to add something, so don’t worry.
In shell scripts, one-line comments start with a #. Comments are ignored by the interpreter, but they serve to instruct the human reading the script on what should the script do.
There also exist multi-line comments; see (“Shell Comments,” n.d.).
The first part of a shell script is called a shebang. A shebang tells the kernel what interpreter to use to execute the script that follows. (Shotts, 2019) By interpreter, I mean the shell. (“Does the shebang determine the shell which runs the script?,” n.d.) You will recognize the shebang because it is the line that starts with #!.
A sidenote: shell scripts are interpreted, not compiled.
Let’s now write a shebang in our script. Let’s name our script tutorialScript.sh. In it, write the following as the first line:
#!/bin/bash
That tells the kernel to interpret our script using the bash interpreter. You have different-looking shebangs for different interpreters.
Shell scripts ought to be used for automating tasks and file management. That was an assertion made by (Ward, 2014) and I agree with that.
If you ever need to do something more than manipulate files or automate tasks, shell scripts probably aren’t the ideal choice for it. I used shell scripts for the following tasks:
seeing a difference between multiple files in two folders
automating a task of starting a program
If I were to use shell scripts for some kind of text manipulation or some calculations, I would use a different programming language. It’s not that shell scripts can’t do calculations or manipulate text, it is that it is easier to do so in other programming languages. So keep in mind: If it is not file management or automation, use another programming language. Pick the right tool for the right task.
Hope you learned something useful!
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Page 250
Shell scripts are commands written in a file. (Ward, 2014) If you were to look at a shell script file, it would be composed of commands. Not everything would be a command though, but you would recognize commands.
So in a sense, we aren’t learning nothing new, but we will learn some things which appear in shell scripts and don’t appear outside them.
Talk soon!
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Page 249
We are about to delve into shell scripting. Shell scripts are used to automate certain things related to files.
It is good to be acquainted with shell scripts if you are a software developer, but if you are a regular user, read this only if you are interested. The aim of this section will be to get you familiar enough with shell scripting to read and write shell scripts, albeit you will need to Google certain details of the things you are trying to achieve (if you are writing your own shell scripts). We will do this by making a very simple shell script which demonstrates the usage of each of the constructs we will learn to use.
Use cron to schedule things periodically; use at to schedule things only once
Every single computer in a computer network has an IP address through which it can be addressed
ip command is used to see information about your network interfaces
Use ping someWebsite to check your Internet connection (you should have no packet loss)
Use ssh to login to a remote host
Use scp for copying files to/from a remote host
X Window System is related to the Linux desktop
Build systems exist to ease the process of creating an executable from source code
To build something from source code do the following: 1. Download the folder with the source code; 2. Run ./configure; 3. Run make; 4. Run make install