Categories
Linux Tutorial Series

Linux Tutorial Series – 185 – The if statement

Here is the video version, if you prefer it:

The if statement allows us to test for a condition and execute a certain set of commands based on the result of that test. (“If Statements!,” n.d.)⁠

An example script:

#!/bin/bash

if [ "$1" = 'Hello' ]

then

echo 'Hello back to you!'

fi

What is happening here? We are testing if the first argument to our script is Hello. If it is, we echo Hello back to you! and if it is not, we don’t do anything.

More technically, the [ is a command that performs tests for Unix conditionals. (Ward, 2014)⁠ The if, then and fi are shell keywords and everything else is a command. So what happens is that we check if the first argument to our shell script is indeed equal to Hello. If it is, then we echo Hello back to you!. If it is not, we don’t echo out anything.

A detail – the [ command returns an exit code. If the exit code is 0 (as we learned) that means that the check went well and we go on to echo Hello back to you! and if the exit code is non-zero we know that something went wrong and we don’t echo out anything.

Another detail: why did we surround the $1 in quotes above? Because if we don’t pass the first argument (it is empty), we get an error like so:

mislav@mislavovo-racunalo:~/Linux_folder$ ./tutorialScript2.sh

./tutorialScript2.sh: line 2: [: =: unary operator expected

because we don’t supply anything for the missing argument and then we have a gap between the [ and the =. However, when we surround the argument with quotes and don’t supply the argument, we get a so-called empty string (meaning empty sequence of characters). If we use the quotes, we don’t get that error.

Hope you learned something useful!

References

If Statements! (n.d.). Retrieved March 7, 2020, from https://ryanstutorials.net/bash-scripting-tutorial/bash-if-statements.php

Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 256-257

Categories
Linux Tutorial Series

Linux Tutorial Series – 184 – How did it go – exit codes

Here is the video version, if you prefer it:

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

1264.txt aba2.txt ab-hard a-symbolic file.txt

1-4.txt~ aba2.txt~ ab-new.txt a.txt~ tutorialScript.sh

2345.txt aba.txt ab.txt~ cb.txt tutorialScript.sh~

ab2.txt aba.txt~ a-new.txt cb.txt~

mislav@mislavovo-racunalo:~/Linux_folder$ echo $?

0

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)⁠

Hope you learned something new!

Categories
Linux Tutorial Series

Linux Tutorial Series – 183.1 – A note – we are using variables

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.

Thank you for reading!

Categories
Linux Tutorial Series

Linux Tutorial Series – 183 – Special variables

Here is the video version, if you prefer it:

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:

mislav@mislavovo-racunalo:~/Linux_folder$ ./tutorialScript.sh

bash: ./tutorialScript.sh: Permission denied

Ooops! Let’s fix this by giving our user execute permissions. How to do so? Well, chmod of course:

mislav@mislavovo-racunalo:~/Linux_folder$ chmod 755 tutorialScript.sh

Now let’s run our script and pass it an argument as so:

mislav@mislavovo-racunalo:~/Linux_folder$ ./tutorialScript.sh argument1

argument1

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

Categories
Linux Tutorial Series

Linux Tutorial Series – 182 – Quoting and string literals

Here is the video version, if you prefer it:

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)⁠

  1. Before running the command, the shell performs substitutions on variables and globs
  2. The shell passes the results of the substitutions to the command

To illustrate this, here is an example:

mislav@mislavovo-racunalo:~$ ls

anaconda3 grep-hadoop-example Public TUTORIAL

'Calibre Library' hadoop-example Python-3.7.4 TUTORIAL~

Desktop Linux_folder snap Untitled.ipynb

Documents Music stanfordnlp_resources Videos

Downloads Pictures Templates

mislav@mislavovo-racunalo:~$ echo A*

A*

mislav@mislavovo-racunalo:~$ echo a*

anaconda3

mislav@mislavovo-racunalo:~$ echo C*

Calibre Library

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:

mislav@mislavovo-racunalo:~$ echo "$PATH"

/home/mislav/anaconda3/condabin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/mislav/Python-3.7.4/bin:/usr/lib/jvm/jdk1.8.0_231/bin:/usr/lib/jvm/jdk1.8.0_231/db/bin:/usr/lib/jvm/jdk1.8.0_231/jre/bin:/home/mislav/Downloads/hadoop-2.10.0/bin:/home/mislav/Downloads/hadoop-2.10.0/sbin:/home/mislav/anaconda3/bin

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.

Hope you learned something useful!

References

How to escape single quotes within single quoted strings. (n.d.). Retrieved February 21, 2020, from https://stackoverflow.com/questions/1250079/how-to-escape-single-quotes-within-single-quoted-strings/16605140#16605140

Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 251-253

Categories
Linux Tutorial Series

Linux Tutorial Series – 181 – Comments

Here is the video version, if you prefer it:

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.)⁠.

Thank you for reading!

References

Shell Comments. (n.d.). Retrieved March 7, 2020, from https://bash.cyberciti.biz/guide/Shell_Comments

Categories
Linux Tutorial Series

Linux Tutorial Series – 180 – Shebang

Here is the video version, if you prefer it:

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.

Hope you learned something useful!

References

Does the shebang determine the shell which runs the script? (n.d.). Retrieved February 21, 2020, from https://unix.stackexchange.com/questions/87560/does-the-shebang-determine-the-shell-which-runs-the-script

Shotts, W. (2019). The Linux Command Line, Fifth Internet Edition. Retrieved from http://linuxcommand.org/tlcl.php. Page 389

Categories
Linux Tutorial Series

Linux Tutorial Series – 179 – Shell scripts – when and when not to use them

Here is the video version, if you prefer it:

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

Categories
Linux Tutorial Series

Linux Tutorial Series – 178 – What are shell scripts?

Here is the video version, if you prefer it:

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

Categories
Linux Tutorial Series

Linux Tutorial Series – 177 – Checkpoint

Here is the video version, if you prefer it:

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.

Talk soon!