In this article, we'll start with the basics of bash scripting which includes variables, commands, inputs/ outputs, and debugging. We'll also see examples of each along the way.

Let's get started. 🚀

Table of Contents

1. Pre-requisites
2. Introduction
3. Definition of Bash scripting
4. Advantages of Bash scripting
5. Overview of Bash shell and command line interface
6. How to Get Started with Bash Scripting
7. How to Run Bash Commands from the Command Line
8. How to Create and Execute Bash Scripts

9. Bash Scripting Basics

10. Comments in bash scripting

11. Variables and data types in Bash
12. Input and output in Bash scripts
13. Basic Bash commands (echo, read, etc.)

14. Conditional statements (if/else)

15. Looping and Branching in Bash

16. While loop
17. For loop
18. Case statements
19. How to Schedule Scripts using cron
20. How to Debug and Troubleshoot Bash Scripts
21. Conclusion
22. Resources for learning more about Bash scripting

Pre-requisites

To follow along with this tutorial, you should have the following accesses:

• A running version of Linux with access to the command line.

If you do not have Linux installed or you are just starting out, you can easily access the Linux command line through Replit. Replit is a browser-based IDE where you can access the bash shell in a few minutes.

You can also install Linux on top of your Windows system using WSL (Windows Subsystem for Linux). Here is a tutorial for that.

Introduction

Definition of Bash scripting

A bash script is a file containing a sequence of commands that are executed by the bash program line by line. It allows you to perform a series of actions, such as navigating to a specific directory, creating a folder, and launching a process using the command line.

By saving these commands in a script, you can repeat the same sequence of steps multiple times and execute them by running the script.

Advantages of Bash scripting

Bash scripting is a powerful and versatile tool for automating system administration tasks, managing system resources, and performing other routine tasks in Unix/Linux systems. Some advantages of shell scripting are:

• Automation: Shell scripts allow you to automate repetitive tasks and processes, saving time and reducing the risk of errors that can occur with manual execution.
• Portability: Shell scripts can be run on various platforms and operating systems, including Unix, Linux, macOS, and even Windows through the use of emulators or virtual machines.
• Flexibility: Shell scripts are highly customizable and can be easily modified to suit specific requirements. They can also be combined with other programming languages or utilities to create more powerful scripts.
• Accessibility: Shell scripts are easy to write and don't require any special tools or software. They can be edited using any text editor, and most operating systems have a built-in shell interpreter.
• Integration: Shell scripts can be integrated with other tools and applications, such as databases, web servers, and cloud services, allowing for more complex automation and system management tasks.
• Debugging: Shell scripts are easy to debug, and most shells have built-in debugging and error-reporting tools that can help identify and fix issues quickly.

Overview of Bash shell and command line interface

The terms "shell" and "bash" are used interchangeably. But there is a subtle difference between the two.

The term "shell" refers to a program that provides a command-line interface for interacting with an operating system. Bash (Bourne-Again SHell) is one of the most commonly used Unix/Linux shells and is the default shell in many Linux distributions.

A shell or command-line interface looks like this:

The shell accepts commands from the user and displays the output

In the above output, zaira@Zaira is the shell prompt. When a shell is used interactively, it displays a $ when it is waiting for a command from the user.

If the shell is running as root (a user with administrative rights), the prompt is changed to #. The superuser shell prompt looks like this:

[root@host ~]#

Although Bash is a type of shell, there are other shells available as well, such as Korn shell (ksh), C shell (csh), and Z shell (zsh). Each shell has its own syntax and set of features, but they all share the common purpose of providing a command-line interface for interacting with the operating system.

You can determine your shell type using the ps command:

ps

Here is the output for me:

Checking the shell type. I'm using bash shell

In summary, while "shell" is a broad term that refers to any program that provides a command-line interface, "Bash" is a specific type of shell that is widely used in Unix/Linux systems.

Note: In this tutorial, we will be using the "bash" shell.

How to Get Started with Bash Scripting

Running Bash commands from the command line

As mentioned earlier, the shell prompt looks something like this:

[username@host ~]$

You can enter any command after the $ sign and see the output on the terminal.

Generally, commands follow this syntax:

command [OPTIONS] arguments

Let's discuss a few basic bash commands and see their outputs. Make sure to follow along :)

• date: Displays the current date

zaira@Zaira:~/shell-tutorial$ date
Tue Mar 14 13:08:57 PKT 2023

• pwd: Displays the present working directory.

zaira@Zaira:~/shell-tutorial$ pwd
/home/zaira/shell-tutorial

• ls: Lists the contents of the current directory.

zaira@Zaira:~/shell-tutorial$ ls
check_plaindrome.sh  count_odd.sh  env  log  temp

• echo: Prints a string of text, or value of a variable to the terminal.

zaira@Zaira:~/shell-tutorial$ echo "Hello bash"
Hello bash

You can always refer to a commands manual with the man command.

For example, the manual for ls looks something like this:

You can see options for a command in detail using man

How to Create and Execute Bash scripts

Script naming conventions

By naming convention, bash scripts end with .sh. However, bash scripts can run perfectly fine without the sh extension.

Adding the Shebang

Bash scripts start with a shebang. Shebang is a combination of bash # and bang ! followed by the bash shell path. This is the first line of the script. Shebang tells the shell to execute it via bash shell. Shebang is simply an absolute path to the bash interpreter.

Below is an example of the shebang statement.

#!/bin/bash

You can find your bash shell path (which may vary from the above) using the command:

which bash

Creating our first bash script

Our first script prompts the user to enter a path. In return, its contents will be listed.

Create a file named run_all.sh using the vi command. You can use any editor of your choice.

vi run_all.sh

Add the following commands in your file and save it:

#!/bin/bash
echo "Today is " `date`

echo -e "\nenter the path to directory"
read the_path

echo -e "\n you path has the following files and folders: "
ls $the_path

Let's take a deeper look at the script line by line. I am displaying the same script again, but this time with line numbers.

  1 #!/bin/bash
  2 echo "Today is " `date`
  3
  4 echo -e "\nenter the path to directory"
  5 read the_path
  6
  7 echo -e "\n you path has the following files and folders: "
  8 ls $the_path

• Line #1: The shebang (#!/bin/bash) points toward the bash shell path.
• Line #2: The echo command is displaying the current date and time on the terminal. Note that the date is in backticks.
• Line #4: We want the user to enter a valid path.
• Line #5: The read command reads the input and stores it in the variable the_path.
• line #8: The ls command takes the variable with the stored path and displays the current files and folders.

Executing the bash script

To make the script executable, assign execution rights to your user using this command:

chmod u+x run_all.sh

Here,

• chmod modifies the ownership of a file for the current user :u.
• +x adds the execution rights to the current user. This means that the user who is the owner can now run the script.
• run_all.sh is the file we wish to run.

You can run the script using any of the mentioned methods:

• sh run_all.sh
• bash run_all.sh
• ./run_all.sh

Let's see it running in action 🚀

Bash Scripting Basics

Comments in bash scripting

Comments start with a # in bash scripting. This means that any line that begins with a # is a comment and will be ignored by the interpreter.

Comments are very helpful in documenting the code, and it is a good practice to add them to help others understand the code.

These are examples of comments:

# This is an example comment
# Both of these lines will be ignored by the interpreter

Variables and data types in Bash

Variables let you store data. You can use variables to read, access, and manipulate data throughout your script.

There are no data types in Bash. In Bash, a variable is capable of storing numeric values, individual characters, or strings of characters.

In Bash, you can use and set the variable values in the following ways:

1. Assign the value directly:

country=Pakistan

2. Assign the value based on the output obtained from a program or command, using command substitution. Note that $ is required to access an existing variable's value.

same_country=$country

To access the variable value, append $ to the variable name.

zaira@Zaira:~$ country=Pakistan
zaira@Zaira:~$ echo $country
Pakistan
zaira@Zaira:~$ new_country=$country
zaira@Zaira:~$ echo $new_country
Pakistan

Variable naming conventions

In Bash scripting, the following are the variable naming conventions:

1. Variable names should start with a letter or an underscore (_).
2. Variable names can contain letters, numbers, and underscores (_).
3. Variable names are case-sensitive.
4. Variable names should not contain spaces or special characters.
5. Use descriptive names that reflect the purpose of the variable.
6. Avoid using reserved keywords, such as if, then, else, fi, and so on as variable names.

Here are some examples of valid variable names in Bash:

name
count
_var
myVar
MY_VAR

And here are some examples of invalid variable names:

2ndvar (variable name starts with a number)
my var (variable name contains a space)
my-var (variable name contains a hyphen)

Following these naming conventions helps make Bash scripts more readable and easier to maintain.

Input and output in Bash scripts

Gathering input

In this section, we'll discuss some methods to provide input to our scripts.

1. Reading the user input and storing it in a variable

We can read the user input using the read command.

#!/bin/bash 

echo "What's your name?" 

read entered_name 

echo -e "\nWelcome to bash tutorial" $entered_name

2. Reading from a file

This code reads each line from a file named input.txt and prints it to the terminal. We'll study while loops later in this article.

while read line
do
  echo $line
done < input.txt

3. Command line arguments

In a bash script or function, $1 denotes the initial argument passed, $2 denotes the second argument passed, and so forth.

This script takes a name as a command-line argument and prints a personalized greeting.

echo "Hello, $1!"

We have supplied Zaira as our argument to the script.

#!/bin/bash
echo "Hello, $1!"

Output:

Displaying output

Here we'll discuss some methods to receive output from the scripts.

1. Printing to the terminal:

echo "Hello, World!"

This prints the text "Hello, World!" to the terminal.

2. Writing to a file:

echo "This is some text." > output.txt

This writes the text "This is some text." to a file named output.txt. Note that the >operator overwrites a file if it already has some content.

3. Appending to a file:

echo "More text." >> output.txt

This appends the text "More text." to the end of the file output.txt.

4. Redirecting output:

ls > files.txt

This lists the files in the current directory and writes the output to a file named files.txt. You can redirect output of any command to a file this way.

Basic Bash commands (echo, read, etc.)

Here is a list of some of the most commonly used bash commands:

1. cd: Change the directory to a different location.
2. ls: List the contents of the current directory.
3. mkdir: Create a new directory.
4. touch: Create a new file.
5. rm: Remove a file or directory.
6. cp: Copy a file or directory.
7. mv: Move or rename a file or directory.
8. echo: Print text to the terminal.
9. cat: Concatenate and print the contents of a file.
10. grep: Search for a pattern in a file.
11. chmod: Change the permissions of a file or directory.
12. sudo: Run a command with administrative privileges.
13. df: Display the amount of disk space available.
14. history: Show a list of previously executed commands.
15. ps: Display information about running processes.

Conditional statements (if/else)

Expressions that produce a boolean result, either true or false, are called conditions. There are several ways to evaluate conditions, including if, if-else, if-elif-else, and nested conditionals.

Syntax:

if [[ condition ]];
then
    statement
elif [[ condition ]]; then
    statement 
else
    do this by default
fi

We can use logical operators such as AND -a and OR -o to make comparisons that have more significance.

if [ $a -gt 60 -a $b -lt 100 ]

Let's see an example of a Bash script that uses if, if-else, and if-elif-else statements to determine if a user-inputted number is positive, negative, or zero:

#!/bin/bash

echo "Please enter a number: "
read num

if [ $num -gt 0 ]; then
  echo "$num is positive"
elif [ $num -lt 0 ]; then
  echo "$num is negative"
else
  echo "$num is zero"
fi

The script first prompts the user to enter a number. Then, it uses an if statement to check if the number is greater than 0. If it is, the script outputs that the number is positive. If the number is not greater than 0, the script moves on to the next statement, which is an if-elif statement. Here, the script checks if the number is less than 0. If it is, the script outputs that the number is negative. Finally, if the number is neither greater than 0 nor less than 0, the script uses an else statement to output that the number is zero.

Seeing it in action 🚀

Looping and Branching in Bash

While loop

While loops check for a condition and loop until the condition remains true. We need to provide a counter statement that increments the counter to control loop execution.

In the example below, (( i += 1 )) is the counter statement that increments the value of i. The loop will run exactly 10 times.

#!/bin/bash
i=1
while [[ $i -le 10 ]] ; do
   echo "$i"
  (( i += 1 ))
done

For loop

The for loop, just like the while loop, allows you to execute statements a specific number of times. Each loop differs in its syntax and usage.

In the example below, the loop will iterate 5 times.

#!/bin/bash

for i in {1..5}
do
    echo $i
done

Case statements

In Bash, case statements are used to compare a given value against a list of patterns and execute a block of code based on the first pattern that matches. The syntax for a case statement in Bash is as follows:

case expression in
    pattern1)
        # code to execute if expression matches pattern1
        ;;
    pattern2)
        # code to execute if expression matches pattern2
        ;;
    pattern3)
        # code to execute if expression matches pattern3
        ;;
    *)
        # code to execute if none of the above patterns match expression
        ;;
esac

Here, "expression" is the value that we want to compare, and "pattern1", "pattern2", "pattern3", and so on are the patterns that we want to compare it against.

The double semicolon ";;" separates each block of code to execute for each pattern. The asterisk "*" represents the default case, which executes if none of the specified patterns match the expression.

Let's see an example.

fruit="apple"

case $fruit in
    "apple")
        echo "This is a red fruit."
        ;;
    "banana")
        echo "This is a yellow fruit."
        ;;
    "orange")
        echo "This is an orange fruit."
        ;;
    *)
        echo "Unknown fruit."
        ;;
esac

In this example, since the value of "fruit" is "apple", the first pattern matches, and the block of code that echoes "This is a red fruit." is executed. If the value of "fruit" were instead "banana", the second pattern would match and the block of code that echoes "This is a yellow fruit." would execute, and so on. If the value of "fruit" does not match any of the specified patterns, the default case is executed, which echoes "Unknown fruit."

How to Schedule Scripts using cron

Cron is a powerful utility for job scheduling that is available in Unix-like operating systems. By configuring cron, you can set up automated jobs to run on a daily, weekly, monthly, or specific time basis. The automation capabilities provided by cron play a crucial role in Linux system administration.

Below is the syntax to schedule crons:

# Cron job example
* * * * * sh /path/to/script.sh

Here, the *s represent minute(s) hour(s) day(s) month(s) weekday(s), respectively.

Below are some examples of scheduling cron jobs.

Using crontab

The crontab utility is used to add and edit the cron jobs.

crontab -l lists the already scheduled scripts for a particular user.

You can add and edit the cron through crontab -e.

You can read more about corn jobs in my other article here.

How to Debug and Troubleshoot Bash Scripts

Debugging and troubleshooting are essential skills for any Bash scripter. While Bash scripts can be incredibly powerful, they can also be prone to errors and unexpected behavior. In this section, we will discuss some tips and techniques for debugging and troubleshooting Bash scripts.

Set the set -x option

One of the most useful techniques for debugging Bash scripts is to set the set -x option at the beginning of the script. This option enables debugging mode, which causes Bash to print each command that it executes to the terminal, preceded by a + sign. This can be incredibly helpful in identifying where errors are occurring in your script.

#!/bin/bash

set -x

# Your script goes here

Check the exit code

When Bash encounters an error, it sets an exit code that indicates the nature of the error. You can check the exit code of the most recent command using the $? variable. A value of 0 indicates success, while any other value indicates an error.

#!/bin/bash

# Your script goes here

if [ $? -ne 0 ]; then
    echo "Error occurred."
fi

Use echo statements

Another useful technique for debugging Bash scripts is to insert echo statements throughout your code. This can help you identify where errors are occurring and what values are being passed to variables.

#!/bin/bash

# Your script goes here

echo "Value of variable x is: $x"

# More code goes here

Use the set -e option

If you want your script to exit immediately when any command in the script fails, you can use the set -e option. This option will cause Bash to exit with an error if any command in the script fails, making it easier to identify and fix errors in your script.

#!/bin/bash

set -e

# Your script goes here

Troubleshooting crons by verifying logs

We can troubleshoot crons using the log files. Logs are maintained for all the scheduled jobs. You can check and verify in logs if a specific job ran as intended or not.

For Ubuntu/Debian, you can find cronlogs at:

/var/log/syslog

The location varies for other distributions.

A cron job log file can look like this:

2022-03-11 00:00:01 Task started
2022-03-11 00:00:02 Running script /path/to/script.sh
2022-03-11 00:00:03 Script completed successfully
2022-03-11 00:05:01 Task started
2022-03-11 00:05:02 Running script /path/to/script.sh
2022-03-11 00:05:03 Error: unable to connect to database
2022-03-11 00:05:03 Script exited with error code 1
2022-03-11 00:10:01 Task started
2022-03-11 00:10:02 Running script /path/to/script.sh
2022-03-11 00:10:03 Script completed successfully

Conclusion

In this article, we started with how to access the terminal and then ran some basic bash commands. We also studied what a bash shell is. We briefly looked at branching the code using loops and conditionals. Finally, we discussed automating the scripts using cron followed by some troubleshooting techniques.

Resources for learning more about Bash scripting

If you want to dig deeper into the world of bash scripting, I would suggest you have a look at this 6-hour course on Linux at freeCodeCamp.

What’s your favorite thing you learned from this tutorial? You can also connect with me on any of these platforms. 📧�

See you in the next tutorial, happy coding 😁

Banner image credits: Image by Freepik

When you're starting out learning a new programming language, your very first program is likely to be one that prints "hello world!".

Let's say you want to do this in Python. There are two ways of doing it: using the Python shell or writing it as a script and running it in the terminal.

What is a Shell?

An operating system is made up of a bunch of programs. They perform tasks like file handling, memory management, and resource management, and they help your applications run smoothly.

All the work we do on computers, like analyzing data in Excel or playing games, is facilitated by the operating system.

Operating system programs are of two types, called shell and kernel programs.

Kernel programs are the ones who perform the actual tasks, like creating a file or sending interrupts. Shell is another program, whose job is to take input and decide and execute the required kernel program to do the job and show the output.

The shell is also called the command processor.

What is a Terminal?

The terminal is the program that interacts with the shell and allows us to communicate with it via text-based commands. This is why it's also called the command line.

To access the terminal on Windows, hit the Windows logo + R, type cmd, and press Enter.

To access the terminal on Ubuntu, hit Ctrl + Alt + T.

What is the Python Shell?

Python is an interpreted language. This means that the Python interpreter reads a line of code, executes that line, then repeats this process if there are no errors.

The Python Shell gives you a command line interface you can use to specify commands directly to the Python interpreter in an interactive manner.

You can get a lot of detailed information regarding the Python shell in the official docs.

How to Use the Python Shell

To start the Python shell, simply type python and hit Enter in the terminal:

C:\Users\Suchandra Datta>python
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>print("hello world!")

The interactive shell is also called REPL which stands for read, evaluate, print, loop. It'll read each command, evaluate and execute it, print the output for that command if any, and continue this same process repeatedly until you quit the shell.

There are different ways to quit the shell:

• you can hit Ctrl+Z on Windows or Ctrl+D on Unix systems to quit
• use the exit() command
• use the quit() command

C:\Users\Suchandra Datta>python
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print("HELLO WORLD")
HELLO WORLD
>>> quit()

C:\Users\Suchandra Datta>

C:\Users\Suchandra Datta>python
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

C:\Users\Suchandra Datta>

C:\Users\Suchandra Datta>python
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z


C:\Users\Suchandra Datta>

What Can You Do in the Python Shell?

You can do pretty much everything that the Python language allows, from using variables, loops, and conditions to defining functions and more.

The >>> is the shell prompt where you type in your commands. If you have commands that span across several lines – for example when you define loops – the shell prints the ... characters which signifies that a line continues.

Let's see an example:

>>>
>>> watch_list = ["stranger_things_s1", "stranger_things_s2", "stranger_things_s3","stranger_things_s4"]
>>>
>>>

Here we defined a list with some TV show names via the Python shell.

Next, let's define a function that accepts a list of shows and randomly returns a show:

>>> def weekend_party(show_list):
...     r = random.randint(0, len(show_list)-1)
...     return show_list[r]
...

Note the continuation lines (...) of the Python shell here.

Finally to invoke the function from the shell, you simply call the function the way you would do in a script:

>>> weekend_party(watch_list)
'stranger_things_s1'
>>>
>>>
>>> weekend_party(watch_list)
'stranger_things_s3'
>>>
>>>
>>> weekend_party(watch_list)
'stranger_things_s2'
>>>
>>>
>>> weekend_party(watch_list)
'stranger_things_s2'
>>>
>>>
>>> weekend_party(watch_list)
'stranger_things_s3'
>>>

You can inspect Python modules from the shell, as shown below:

>>>
>>>
>>> import numpy
>>> numpy.__version__
'1.20.1'
>>>

You can see what methods and attributes a module offers by using the dir() method:

>>>
>>> x = dir(numpy)
>>> len(x)
606
>>> x[0:3]
['ALLOW_THREADS', 'AxisError', 'BUFSIZE']

Here you can see that Numpy has 606 methods and properties in total.

How to Run Python Scripts

The Python shell is useful for executing simple programs or for debugging parts of complex programs.

But really large Python programs with a lot of complexity are written in files with a .py extension, typically called Python scripts. Then you execute them from the terminal using the Python command.

The usual syntax is:

python filename.py

All the commands we executed previously via the shell, we can also write it in a script and run in this way.

Conclusion

In this article, we learnt about the shell, terminal, how to use the Python shell. We also saw how to run Python scripts from the command line.

I hope this article helps you understand what the Python shell is and how you can use it in your day to day lives. Happy learning!

The command line is one of the most useful and efficient tools we have as developers and as computer users in general. But using it can feel a bit overwhelming and complex when you're starting out.

In this article I'll try my best to simply explain the parts that make up the command line interface, and the basics of how it works, so you can start using it for your daily tasks.

Let's go! =D

Table of Contents

• Difference between console, terminal, command line (CLI) and Shell

  • Console

  • Terminal

  • Shell

  • Command line (CLI)

• Why should I even care about using the terminal?

• Different kinds of shells

  • A bit of history - Posix

  • How do I know what shell I'm running?

  • What shell is better?

    • A comment about customization

• Most common and useful commands to use

  • Git commands

• Our first script

• Round up

Difference between console, command line (CLI), terminal and Shell

I think a good place to start is to know exactly what the command line is.

When referring to this, you may have heard the terms Terminal, console, command line, CLI, and shell. People often use these words interchangeably but the truth is they're actually different things.

Differentiating each isn't necesarilly crucial knwoledge to have, but it will help clarify things. So lets briefly explain each one.

Console:

The console is the physical device that allows you to interact with the computer.

In plain English, it's your computer screen, keyboard, and mouse. As a user, you interact with your computer through your console.

Terminal:

A terminal is a text input and output environment. It is a program that acts as a wrapper and allows us to enter commands that the computer processes.

In plain English again, it's the "window" in which you enter the actual commands your computer will process.

Keep in mind the terminal is a program, just like any other. And like any program, you can install it and uninstall it as you please. It's also possible to have many terminals installed in your computer and run whichever you want whenever you want.

All operating systems come with a default terminal installed, but there are many options out there to choose from, each with its own functionalities and features.

Shell:

A shell is a program that acts as command-line interpreter. It processes commands and outputs the results. It interprets and processes the commands entered by the user.

Same as the terminal, the shell is a program that comes by default in all operating systems, but can also be installed and uninstalled by the user.

Different shells come with different syntax and characteristics as well. It's also possible to have many shells installed at your computer and run each one whenever you want.

In most Linux and Mac operating systems the default shell is Bash. While on Windows it's Powershell. Some other common examples of shells are Zsh and Fish.

Shells work also as programming languages, in the sense that with them we can build scripts to make our computer execute a certain task. Scripts are nothing more than a series of instructions (commands) that we can save on a file and later on execute whenever we want.

We'll take a look at scripts later on in this article. For now just keep in mind that the shell is the program your computer uses to "understand" and execute your commands, and that you can also use it to program tasks.

Also keep in mind that the terminal is the program in which the shell will run. But both programs are independent. That means, I can have any shell run on any terminal. There's no dependance between both programs in that sense.

Command line or CLI (command line interface):

The CLI is the interface in which we enter commands for the computer to process. In plain English once again, it's the space in which you enter the commands the computer will process.

This is practically the same as the terminal and in my opinion these terms can be used interchangeably.

One interesting thing to mention here is that most operating systems have two different types of interfaces:

• The CLI, which takes commands as inputs in order for the computer to execute tasks.

• The other is the GUI (graphical user interface), in which the user can see things on the screen and click on them and the computer will respond to those events by executing the corresponding task.

Why should I even care about using the terminal?

We just mentioned that most operating systems come with a GUI. So if we can see things on the screen and click around to do whatever we want, you might wonder why you should learn this complicated terminal/cli/shell thing?

The first reason is that for many tasks, it's just more efficient. We'll see some examples in a second, but there are many tasks where a GUI would require many clicks around different windows. But on the CLI these tasks can be executed with a single command.

In this sense, being comfortable with the command line will help you save time and be able to execute your tasks quicker.

The second reason is that by using commands you can easily automate tasks. As previously mentioned, we can build scripts with our shell and later on execute those scripts whenever we want. This is incredibly useful when dealing with repetitive tasks that we don't want to do over and over again.

Just to give some examples, we could build a script that creates a new online repo for us, or that creates a certain infrastructure on a cloud provider for us, or that executes a simpler task like changing our screen wallpaper every hour.

Scripting is a great way to save up time with repetitive tasks.

The third reason is that sometimes the CLI will be the only way in which we'll be able to interact with a computer. Take, for example, the case when you would need to interact with a cloud platform server. In most of these cases, you won't have a GUI available, just a CLI to run commands in.

So being comfortable with the CLI will allow you to interact with computers on all ocassions.

The last reason is it looks cool and it's fun. You don't see movie hackers clicking around their computers, right? ;)

Different kinds of shells

Before diving into the actual commands you can run in your terminal, I think it's important to recognize the different types of shells out there and how to identify which shell you're currently running.

Different shells come with different syntax and different features, so to know exactly what command to enter, you first need to know what shell you're running.

A bit of history – Posix

For shells, there's a common standard called Posix.

Posix works for shells in a very similar way that ECMAScript works for JavaScript. It's a standard that dictates certain characteristics and features that all shells should comply with.

This standard was stablished in the 1980's and most current shells were developed according to that standard. That's why most shells share similar syntax and similar features.

How do I know what shell I'm running?

To know what shell you're currently running, just open your terminal and enter echo $0. This will print the current running program name, which in this case is the actual shell.

What shell is better?

There's not A LOT of difference between most shells. Since most of them comply with the same standard, you'll find that most of them work similarly.

There are some slight differences you might want to know, though:

• As mentioned, Bash is the most widely used and comes installed by default on Mac and Linux.

• Zsh is very similar to Bash, but it was created after it and comes with some nice improvements over it. If you'd like to have more detail about its differences, here's a cool article about it.

• Fish is another commonly used shell that comes with some nice built-in features and configurations such as autocompletion and syntax highlighting. The thing about Fish is that it's not Posix complaint, while Bash and Zsh are. This means that some of the commands you'll be able to run on Bash and Zsh won't run on Fish and viceversa. This makes Fish scripting less compatible with most computers compared to Bash and Zsh.

• There are also other shells like Ash or Dash (the naming just makes everything more confusing, I know...) that are stripped-down versions of Posix shells. This means they only offer the features required in Posix, and nothing else. While Bash and Zsh add more features than what Posix requires.

The fact that shells add more features makes them easier and friendlier to interact with, but slower to execute scripts and commands.

So a common practice is to use this "enhanced" shells like Bash or Zsh for general interaction, and a "stripped" shell like Ash or Dash to execute scripts.

When we get to scripting later on, we'll see how we can define what shell will execute a given script.

If you're interested in a more detailed comparison between these shells, here's a video that explains it really well:

If had to recommend a shell, I would recommend bash as it's the most standard and commonly-used one. This means you'll be able to translate your knowledge into most environments.

But again, truth is there's not A LOT of difference between most shells. So in any case you can try a few and see which one you like best. ;)

A comment about customization

I just mentioned that Fish comes with built-in configuration such as autocompletion and syntax highlighting. This come built-in in Fish, but in Bash or Zsh you can configure these features, too.

The point is that shells are customizable. You can edit how the program works, what commands you have available, what information your prompt shows, and more.

We won't see customization options in detail here, but know that when you install a shell in your computer, certain files will be created on your system. Later on you can edit those files to customize your program.

Also, there are many plugins available online that allow you to customize your shell in an easier way. You just install them and get the features that plugin offers. Some examples are OhMyZsh and Starship.

These customization options are also true for Terminals.

So not only do you have many shell and terminal options to choose from – you also have many configuration options for each shell and terminal.

If you're starting out, all this information can feel a bit overwhelming. But just know that there are many options available, and each option can be customized too. That's it.

Most common and useful commands to use

Now that we have a foundation of how the CLI works, let's dive into the most useful commands you can start to use for your daily tasks.

Keep in mind that these examples will be based on my current configuration (Bash on a Linux OS). But most commands should apply to most configurations anyway.

• Echo prints in the terminal whatever parameter we pass it.

echo Hello freeCodeCamp! // Output: Hello freeCodeCamp!

• pwd stands for print working directory and it prints the "place" or directory we are currently at in the computer.

pwd // Output: /home/German

• ls presents you the contents of the directory you're currently in. It will present you with both the files and other directories your current directory contains.

For example, here I'm on a React project directory I've been working on lately:

ls // Output:
node_modules  package.json  package-lock.json  public  README.md  src

If you pass this command the flag or paremter -a It will also show you hidden files or directories. Like .git or .gitignore files

ls -a // Output:
.   .env  .gitignore    package.json       public     src
..  .git  node_modules  package-lock.json  README.md

• cd is short for Change directory and it will take you from your current directory to another.

While on my home directory, I can enter cd Desktop and it will take me to the Desktop Directory.

If I want to go up one directory, meaning go to the directory that contains the current directory, I can enter cd ..

If you enter cd alone, it will take you straight to your home directory.

• mkdir stands for make directory and it will create a new directory for you. You have to pass the command the directory name parameter.

If I wanted to create a new directory called "Test" I would enter mkdir test.

• rmdir stands for Remove directory and it does just that. It needs the directory name parameter just as mkdir: rmdir test.

• touch allows you to create an empty file in your current directory. As parameters it takes the file name, like touch test.txt.

• rm allows you to delete files, in the same way rmdir allows you to remove directories. rm test.txt

• cp allows you to copy files or directories. This command takes two parameters: the first one is the file or directory you want to copy, and the second one is the destination of your copy (where do you want to copy your file/directory to).

If I want to make a copy of my txt file in the same directory, I can enter the following:

cp test.txt testCopy.txt

See that the directory doesn't change, as for "destination" I enter the new name of the file.

If I wanted to copy the file into a diferent directory, but keep the same file name, I can enter this:

cp test.txt ./testFolder/

And if I wanted to copy to a different folder changing the field name, of course I can enter this:

cp test.txt ./testFolder/testCopy.txt

• mv is short for move, and lets us move a file or directory from one place to another. That is, create it in a new directory and delete it in the previous one (same as you could do by cutting and pasting).

Again, this command takes two paremers, the file or directory we want to move and the destination.

mv test.txt ./testFolder/

We can change the name of the file too in the same command if we want to:

mv test.txt ./testFolder/testCopy.txt

• head allows you to view the beginning of a file or piped data directly from the terminal.

head test.txt // Output:
this is the beginning of my test file

• tail works the same but it will show you the end of the file.

tail test.txt // Output:

this is the end of my test file

• The --help flag can be used on most commands and it will return info on how to use that given command.

cd --help // output:
cd: cd [-L|[-P [-e]] [-@]] [dir]
Change the shell working directory.

Change the current directory to DIR. The default DIR is the value of the HOME shell variable.

The variable CDPATH defines the search path for the directory containing DIR. Alternative directory names in CDPATH are separated by a colon :.

A null directory name is the same as the current directory if DIR begins with ....

• In a similar way, the man command will return info about any particular command.

    man cp // output:

    CP(1)                            User Commands                           CP(1)

    NAME
           cp - copy files and directories

    SYNOPSIS
           cp [OPTION]... [-T] SOURCE DEST
           cp [OPTION]... SOURCE... DIRECTORY
           cp [OPTION]... -t DIRECTORY SOURCE...

    DESCRIPTION
           Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.

           Mandatory  arguments  to  long  options are mandatory for short options
           too.

           -a, --archive
                  same as -dR --preserve=all

           --attributes-only
                  don't copy the file data, just the attributes
    ...

You can even enter man bash and that will return a huge manual about everything there's to know about this shell. ;)

• code will open your default code editor. If you enter the command alone, it just opens the editor with the latest file/directory you opened.

You can also open a given file by passing it as parameter: code test.txt.

Or open a new file by passing the new file name: code thisIsAJsFile.js.

• edit will open text files on your default command line text editor (which if you're on Mac or Linux will likely be either Nano or Vim).

If you open your file and then can't exit your editor, first look at this meme:

And then type :q! and hit enter.

The meme is funny because everyone struggles with CLI text editors at first, as most actions (like exiting the editor) are done with keyboard shortcuts. Using these editors is a whole other topic, so go look for tutorials if you're interested in learning more. ;)

• ctrl+c allows you to exit the current process the terminal is running. For example, if you're creating a react app with npx create-react-app and want to cancel the build at some point, just hit ctrl+c and it will stop.

• Copying text from the terminal can be done with ctrl+shift+c and pasting can be done with ctrl+shift+v

• clear will clear your terminal from all previous content.

• exit will close your terminal and (this is not a command but it's cool too) ctrl+alt+t will open a new terminal for you.

• By pressing up and down keys you can navigate through the previous commands you entered.

• By hitting tab you will get autocompletion based on the text you've written so far. By hitting tab twice you'll get suggestions based on the text you've written so far.

For example if I write edit test and tab twice, I get testFolder/ test.txt. If I write edit test. and hit tab my text autocompletes to edit test.txt

Git commands

Besides working around the file system and installing/uninstalling things, interacting with Git and online repos is probably the most common things you're going to use the terminal for as a developer.

It's a whole lot more efficient to do it from the terminal than by clicking around, so let's take a look at the most useful git commands out there.

• git init will create a new local repository for you.

git init // output:
Initialized empty Git repository in /home/German/Desktop/testFolder/.git/

• git add adds one or more files to staging. You can either detail a specific file to add to staging or add all changed files by typing git add .

• git commit commits your changes to the repository. Commits must always be must be accompanied by the -m flag and commit message.

git commit -m 'This is a test commit' // output:
[master (root-commit) 6101dfe] This is a test commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.js

• git status tells you what branch are you currently on and whether you have changes to commit or not.

git status  // output:
On branch master
nothing to commit, working tree clean

• git clone allows you to clone (copy) a repository into the directory you're currently in. Keep in mind you can clone both remote repositories (in GitHub, GitLab, and so on) and local repositories (those that are stored in your computer).

git clone https://github.com/coccagerman/MazeGenerator.git // output:
Cloning into 'MazeGenerator'...
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 15 (delta 1), reused 11 (delta 0), pack-reused 0
Unpacking objects: 100% (15/15), done.

• git remote add origin is used to detail the URL of the remote repository you're going to use for your project. In case you'd like to change it at some point, you can do it by using the command git remote set-url origin.

git remote add origin https://github.com/coccagerman/testRepo.git

Keep in mind you need to create your remote repo first in order to get its URL. We'll see how you can do this from the command line with a little script later on. ;)

• git remote -v lets you list the current remote repository you're using.

git remote -v // output:
origin    https://github.com/coccagerman/testRepo.git (fetch)
origin    https://github.com/coccagerman/testRepo.git (push)

• git push uploads your commited changes to your remote repo.

git push // output:
Counting objects: 2, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 266 bytes | 266.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0)

• git branch lists all the available branches on your repo and tells you what branch you're currently on. If you want to create a new branch, you just have to add the new branch name as parameter like git branch <branch name>.

git branch // output:
* main

• git checkout moves you from one branch to another. It takes your destination branch as paremeter.

git checkout newBranch // output:
Switched to branch 'newBranch'

• git pull pulls (downloads) the code from your remote repository and combines it with your local repo. This is particularly useful when working in teams, when many developers are working on the same code base. In this case each developer periodically pulls from the remote repo in order to work in a code base that includes the changes done by all the other devs.

If there's new code in your remote repo, the command will return the actual files that were modified in the pull. If not, we get Already up to date.

git pull // output:
Already up to date.

• git diff allows you to view the differences between the branch you're currently in and another.

git diff newBranch // output:
diff --git a/newFileInNewBranch.js b/newFileInNewBranch.js
deleted file mode 100644
index e69de29..0000000

As a side comment, when comparing differences between branches or repos, ussually visual tools like Meld are used. It's not that you can't visualize it directly in the terminal, but this tools are greate for a clearer visualization.

• git merge merges (combines) the branch you're currently in with another. Keep in mind the changes will be incorporated only to the branch you're currently in, not to the other one.

git merge newBranch // output:
Updating f15cf51..3a3d62f
Fast-forward
 newFileInNewBranch.js | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 newFileInNewBranch.js

• git log lists all previous commits you've done in the repo.

git log // output:
commit 3a3d62fe7cea7c09403c048e971a5172459d0948 (HEAD -> main, tag: TestTag, origin/main, newBranch)
Author: German Cocca <german.cocca@avature.net>
Date:   Fri Apr 1 18:48:20 2022 -0300

    Added new file

commit f15cf515dd3ec398210108dce092debf26ff9e12
Author: German Cocca <german.cocca@avature.net>
    ...

• The --help flag will show you information about a given command, exactly the same way it works with bash.

git diff --help // output:
GIT-DIFF(1)                       Git Manual                       GIT-DIFF(1)

NAME
       git-diff - Show changes between commits, commit and working tree, etc

SYNOPSIS
       git diff [options] [<commit>] [--] [<path>...]
       git diff [options] --cached [<commit>] [--] [<path>...]
       ...

Our first script

Now we're ready to get to the truly fun and awesome part of the command line, scripting!

As I mentioned previously, a script is nothing more than a series of commands or instructions that we can execute at any given time. To explain how we can code one, we'll use a simple example that will allow us to create a github repo by running a single command. ;)

• First thing to do is create a .sh file. You can put it wherever want. I called mine newGhRepo.sh.

• Then open it on your text/code editor of choice.

• On our first line, we'll write the following: #! /bin/sh

This is called a shebang, and its function is to declare what shell is going to run this script.

Remember previously when we mentioned that we can use a given shell for general interaction and another given shell for executing a script? Well, the shebang is the instruction that dictates what shell runs the script.

As mentioned too, we're using a "stripped down" shell (also known as sh shells) to run the scripts as they're more efficient (though the difference might be unnoticeable to be honest, It's just a personal preference). In my computer I have dash as my sh shell.

If we wanted this script to run with bash the shebang would be #! /bin/bash

• Our next line will be repoName=$1

Here we're declaring a variable called repoName, and assigning it to the value of the first parameter the script receives.

A parameter is a set of characters that is entered after the script/comand. Like with the cd command, we need to specify a directory parameter in order to change directory (ie: cd testFolder).

A way we can identify parameters within a script is by using dollar sign and the order in which that parameter is expected.

If I'm expecting more than one parameter I could write:

paramOne=$1
paramTwo=$2
paramThree=$3
...

• So we're expecting the repository name as parameter of our script. But what happens if the user forgets to enter it? We need to plan for that so next we're going to code a conditional that keeps asking the user to enter the repo name until that parameter is received.

We can do that like this:

while [ -z "$repoName" ]
do
   echo 'Provide a repository name'
   read -r -p $'Repository name:' repoName
done

What we're doing here is:

1. While the repoName variable is not assigned (while [ -z "$repoName" ])

2. Write to the console this message (echo 'Provide a repository name')

3. Then read whatever input the user provides and assign the input to the repoName variable (read -r -p $'Repository name:' repoName)

• Now that we have our repo name in place, we can create our local Git repo like this:

echo "# $repoName" >> README.md
git init
git add .
git commit -m "First commit"

This is creating a readme file and writting a single line with the repo name (echo "# $repoName" >> README.md) and then initializing the git repo and making a first commit.

• Then it's time to upload our repo to github. To do that we're going to take advantage of the github API in the following command:

curl -u coccagerman https://api.github.com/user/repos -d '{"name": "'"$repoName"'", "private":false}'

curl is a command to transfer data from or to a server, using one of the many supported protocols.

Next we're using the -u flag to declare the user we're creating the repo for (-u coccagerman).

Next comes the endpoint provided by the GitHub API (https://api.github.com/user/repos)

And last we're using the -d flag to pass parameters to this command. In this case we're indicating the repository name (for which we're using our repoName variable) and setting private option to false, since we want our repo to be puiblic.

Lots of other config options are available in the API, so check the docs for more info.

• After running this command, GitHub will prompt us to enter our private token for authentication.

If you don't have a private token yet, you can generate it in GitHub in Settings > Developer settings > Personal access tokens

• Cool, we're almost done now! What we need now is the remote URL of our newly created GitHub repo.

To get that we're going to use curl and the GitHub API again, like this:

GIT_URL=$(curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/coccagerman/"$repoName" | jq -r '.clone_url')

Here we're declaring a variable called GIT_URL and assigning it to whatever the following command returns.

The -H flag sets the header of our request.

Then we pass the GitHub API endpoint, which should contain our user name and repo name (https://api.github.com/repos/coccagerman/"$repoName").

Then we're piping the return value of our request. Piping just means passing the return value of a process as the input value of another process. We can do it with the | symbol like <process1> | <process2>.

And finally we run the jq command, which is a tool for processing JSON inputs. Here we tell it to get the value of .clone_url which is where our remote git URL will be according to the data format provided by the GitHub API.

• And as last step, we rename our master branch to main, add the remote origin we just obtained, and push our code to GitHub! =D

git branch -M main
git remote add origin $GIT_URL
git push -u origin main

Our full script should look something like this:

#! /bin/sh
repoName=$1

while [ -z "$repoName" ]
do
    echo 'Provide a repository name'
    read -r -p $'Repository name:' repoName
done

echo "# $repoName" >> README.md
git init
git add .
git commit -m "First commit"

curl -u <yourUserName> https://api.github.com/user/repos -d '{"name": "'"$repoName"'", "private":false}'

GIT_URL=$(curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/<yourUserName>/"$repoName" | jq -r '.clone_url')

git branch -M main
git remote add origin $GIT_URL
git push -u origin main

• Now it's time to test our script! To execute it there're two things we can do.

One option is to enter the shell name and pass the file as parameter, like: dash ../ger/code/projects/scripts/newGhRepo.sh.

And the other is to make the file executable by running chmod u+x ../ger/code/projects/scripts/newGhRepo.sh.

Then you can just execute the file directly by running ../ger/code/projects/scripts/newGhRepo.sh.

And that's it! We have our script up and running. Everytime we need a new repo we can just execute this script from whatever directory we're in.

But there's something a bit annoying about this. We need to remember the exact route of the script directory. Wouldn't it be cool to execute the script with a single command that it's always the same independently of what directory we're at?

In come bash aliases to solve our problem.

Aliases are a way bash provides for making names for exact commands we want to run.

To create a new alias, we need to edit the bash configuration files in our system. This files are normally located in the home directory. Aliases can be defined in different files (mainly .bashrc or .bash_aliases).

I have a .bash_aliases file on my system, so let's edit that.

• In our CLI we enter cd to go over home directory.

• Then we can enter ls -a to list all files (includen hidden ones) and check if we have either a .bashrc or .bash_aliases file in our system.

• We open the file with our text/code editor of choice.

• And we write our new alias like this: alias newghrepo="dash /home/German/Desktop/ger/code/projects/scripts/newGhRepo.sh"

Here I'm declaring the alias name, the actual command I'm going to enter to run the script (newghrepo).

And between quotes, define what that alias is going to do ("dash /home/German/Desktop/ger/code/projects/scripts/newGhRepo.sh")

See that I'm passing the absolute path of the script, so that this command works the same no matter what my current directory is.

If you don't know what the absolute path of your script is, go to the script directory on your terminal and enter readlink -f newGhRepo.sh. That should return the full path for you. ;)

• After we're done editing, we save our file, restart our terminal, and voilà! Now we can run our script by just entering newghrepo, no matter in what directory we currently are. Much quicker than opening the browser and clicking around to create our repo! =D

I hope this gives you a little taste of the kind of optimizations that are possible with scripting. It certainly requires a bit more work the first time you write, test, and set up the script. But after that, you'll never have to perform that task manually again. ;)

Round up

The terminal can feel like an intimidating and intricate place when you're starting out. But it's certainly worth it to put time and effort into learning the ins and outs of it. The efficiency benefits are too good to pass up!

If you're interested in learning more about the terminal and Bash, Zach Gollwitzer has an awesome crash course series on youtube. He has also great tutorials on other topics such as Node and Javascript, so I recommend that you follow him. ;)

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on linkedin or twitter.

Cheers and see you in the next one! =D

This saves you time because you don't have to write certain commands again and again. You can perform daily tasks efficiently and even schedule them for automatic execution.

You can also set certain scripts to execute on startup such as showing a particular message on launching a new session or setting certain environment variables.

The applications and uses of scripting are numerous, so let's dive in.

In this article, you will learn:

1. What is a bash shell?

2. What is a bash script and how do you identify it?

3. How to create your first bash script and execute it.

4. The basic syntax of shell scripting.

5. How to see a system's scheduled scripts.

6. How to automate scripts by scheduling via cron jobs.

The best way to learn is by practicing. I highly encourage you to follow along using Replit. You can access a running Linux shell within minutes.

Introduction to the Bash Shell

The Linux command line is provided by a program called the shell. Over the years, the shell program has evolved to cater to various options.

Different users can be configured to use different shells. But most users prefer to stick with the current default shell. The default shell for many Linux distros is the GNU Bourne-Again Shell (bash). Bash succeeded the Bourne shell (sh).

When you first launch the shell, it uses a startup script located in the .bashrc or .bash_profile file which allows you to customize the behavior of the shell.

When a shell is used interactively, it displays a $ when it is waiting for a command from the user. This is called the shell prompt.

[username@host ~]$

If shell is running as root, the prompt is changed to #. The superuser shell prompt looks like this:

[root@host ~]#

Bash is very powerful as it can simplify certain operations that are hard to accomplish efficiently with a GUI. Remember that most servers do not have a GUI, and it is best to learn to use the powers of a command line interface (CLI).

What is a Bash Script?

A bash script is a series of commands written in a file. These are read and executed by the bash program. The program executes line by line.

For example, you can navigate to a certain path, create a folder and spawn a process inside it using the command line.

You can do the same sequence of steps by saving the commands in a bash script and running it. You can run the script any number of times.

How Do You Identify a Bash Script?

File extension of .sh.

By naming conventions, bash scripts end with a .sh. However, bash scripts can run perfectly fine without the sh extension.

Scripts start with a bash bang.

Scripts are also identified with a shebang. Shebang is a combination of bash # and bang ! followed the the bash shell path. This is the first line of the script. Shebang tells the shell to execute it via bash shell. Shebang is simply an absolute path to the bash interpreter.

Below is an example of the shebang statement.

#! /bin/bash

The path of the bash program can vary. We will see later how to identify it.

Execution rights

Scripts have execution rights for the user executing them.

An execution right is represented by x. In the example below, my user has the rwx (read, write, execute) rights for the file test_script.sh

File colour

Executable scripts appear in a different colour from rest of the files and folders.

In my case, the scripts with execution rights appear as green.

How to Create Your First Bash Script

Let's create a simple script in bash that outputs Hello World.

Create a file named hello_world.sh

touch hello_world.sh

Find the path to your bash shell.

which bash

In my case, the path is /usr/bin/bash and I will include this in the shebang.

Write the command.

We will echo "hello world" to the console.

Our script will look something like this:

#! /usr/bin/bash
echo "Hello World"

Edit the file hello_world.sh using a text editor of your choice and add the above lines in it.

Provide execution rights to your user.

Modify the file permissions and allow execution of the script by using the command below:

chmod u+x hello_world.sh

chmod modifies the existing rights of a file for a particular user. We are adding +x to user u.

Run the script.

You can run the script in the following ways:

./hello_world.sh

bash hello_world.sh.

Here's the output:

Two ways to run scripts

The Basic Syntax of Bash Scripting

Just like any other programming language, bash scripting follows a set of rules to create programs understandable by the computer. In this section, we will study the syntax of bash scripting.

How to define variables

We can define a variable by using the syntax variable_name=value. To get the value of the variable, add $ before the variable.

#!/bin/bash
# A simple variable example
greeting=Hello
name=Tux
echo $greeting $name

Tux is also the name of the Linux mascot, the penguin.

Hi, I am Tux.

Arithmetic Expressions

Below are the operators supported by bash for mathematical calculations:

Let's run a few examples.

Note the spaces, these are part of the syntax

Numerical expressions can also be calculated and stored in a variable using the syntax below:

var=$((expression))

Let's try an example.

#!/bin/bash

var=$((3+9))
echo $var

Fractions are not correctly calculated using the above methods and truncated.

For decimal calculations, we can use bc command to get the output to a particular number of decimal places. bc (Bash Calculator) is a command line calculator that supports calculation up to a certain number of decimal points.

echo "scale=2;22/7" | bc

Where scale defines the number of decimal places required in the output.

Getting output to 2 decimal places

How to read user input

Sometimes you'll need to gather user input and perform relevant operations.

In bash, we can take user input using the read command.

read variable_name

To prompt the user with a custom message, use the -p flag.

read -p "Enter your age" variable_name

Example:

#!/bin/bash

echo "Enter a numner"
read a

echo "Enter a numner"
read b

var=$((a+b))
echo $var

Numeric Comparison logical operators

Comparison is used to check if statements evaluate to true or false. We can use the below shown operators to compare two statements:

Syntax:

if [ conditions ]
    then
         commands
fi

Example:

Let's compare two numbers and find their relationship:

read x
read y

if [ $x -gt $y ]
then
echo X is greater than Y
elif [ $x -lt $y ]
then
echo X is less than Y
elif [ $x -eq $y ]
then
echo X is equal to Y
fi

Output:

Conditional Statements (Decision Making)

Conditions are expressions that evaluate to a boolean expression (true or false). To check conditions, we can use if, if-else, if-elif-else and nested conditionals.

The structure of conditional statements is as follows:

• if...then...fi statements

• if...then...else...fi statements

• if..elif..else..fi

• if..then..else..if..then..fi..fi.. (Nested Conditionals)

Syntax:

if [[ condition ]]
then
    statement
elif [[ condition ]]; then
    statement 
else
    do this by default
fi

To create meaningful comparisons, we can use AND -a and OR -o as well.

The below statement translates to: If a is greater than 40 and b is less than 6.

if [ $a -gt 40 -a $b -lt 6 ]

Example: Let's find the triangle type by reading the lengths of its sides.

read a
read b
read c

if [ $a == $b -a $b == $c -a $a == $c ]
then
echo EQUILATERAL

elif [ $a == $b -o $b == $c -o $a == $c ]
then 
echo ISOSCELES
else
echo SCALENE

fi

Output:

Test case #1

Test case #2

Test case #3

Looping and skipping

For loops allow you to execute statements a specific number of times.

Looping with numbers:

In the example below, the loop will iterate 5 times.

#!/bin/bash

for i in {1..5}
do
    echo $i
done

Looping with strings:

We can loop through strings as well.

#!/bin/bash

for X in cyan magenta yellow  
do
    echo $X
done

While loop

While loops check for a condition and loop until the condition remains true. We need to provide a counter statement that increments the counter to control loop execution.

In the example below, (( i += 1 )) is the counter statement that increments the value of i.

Example:

#!/bin/bash
i=1
while [[ $i -le 10 ]] ; do
   echo "$i"
  (( i += 1 ))
done

Reading files

Suppose we have a file sample_file.txt as shown below:

We can read the file line by line and print the output on the screen.

#!/bin/bash

LINE=1

while read -r CURRENT_LINE
    do
        echo "$LINE: $CURRENT_LINE"
    ((LINE++))
done < "sample_file.txt"

Output:

Lines with line number printed

How to execute commands with back ticks

If you need to include the output of a complex command in your script, you can write the statement inside back ticks.

Syntax:

var= commands

Example: Suppose we want to get the output of a list of mountpoints with tmpfs in their name. We can craft a statement like this: df -h | grep tmpfs.

To include it in the bash script, we can enclose it in back ticks.

#!/bin/bash

var=`df -h | grep tmpfs`
echo $var

Output:

How to get arguments for scripts from the command line

It is possible to give arguments to the script on execution.

$@ represents the position of the parameters, starting from one.

#!/bin/bash

for x in $@
do
    echo "Entered arg is $x"
done

Run it like this:

./script arg1 arg2

How to Automate Scripts by Scheduling via cron Jobs

Cron is a job scheduling utility present in Unix like systems. You can schedule jobs to execute daily, weekly, monthly or in a specific time of the day. Automation in Linux heavily relies on cron jobs.

Below is the syntax to schedule crons:

# Cron job example
* * * * * sh /path/to/script.sh

Here, * represents minute(s) hour(s) day(s) month(s) weekday(s), respectively.

Below are some examples of scheduling cron jobs.

You can learn about cron in detail in this blog post.

How to Check Existing Scripts in a System

Using crontab

crontab -l lists the already scheduled scripts for a particular user.

My scheduled scripts

Using the find command

The find command helps to locate files based on certain patterns. As most of the scripts end with .sh, we can use the find script like this:

find . -type f -name "*.sh"

Where,

• . represents the current directory. You can change the path accordingly.

• -type f indicates that the file type we are looking for is a text based file.

• *.sh tells to match all files ending with .sh.

If you are interested to read about the find command in detail, check my other post.

Wrapping up

In this tutorial we learned the basics of shell scripting. We looked into examples and syntax which can help us write meaningful programs.

What’s your favorite thing you learned from this tutorial? Let me know on Twitter!

You can read my other posts here.

Work vector created by macrovector - www.freepik.com

First, they can help make you more productive. But not only that - you'll be able to have that productive setup you created for youself on any machine.

This article is an introduction on how to get started with dotfiles.

You'll learn what they are, how to locate them on your system, and how to create a couple of simple dotfiles. In addition I'll give you some suggestions and resources on how to customise your settings and expand your knowledge.

Let's get started!

What are dotfiles?

Many computer software programs store their configuration settings in plain, text-based files or directories.

Dotfiles are configuration files for various programs, and they help those programs manage their functionality.

What sets them apart from regular files and directories is their prefix.

Dotfiles are named that way because each file and directory starts with a dot (.)

On Unix based systems, dotfiles are hidden by the Operating System by default.

Examples of common dotfiles

Most programs store their configurations in your home directory by default.

Some common dotfiles that you may have heard of or used before are:

• If you use the Bash shell, you might have a .bash_profile and .bashrc file, both of which contain scripts that load each time you start a new terminal session and configure the shell.
• If you use the Zsh shell, which is the new default for MacOS, you would have (or would've created) a .zshrc file which configures and customises the shell.
• If you use the command line code editor Vim, you would store its configurations in a .vimrc file.
• After setting up and configuring Git on your local machine, you would have a .gitconfig file, which would contain all your information and settings.
• Many programs, instead of storing their configurations in your home directory, instead store them in the hidden .config directory (folder) on your system.

How to Find Dotfiles

In Finder, the root of your Home directory might look something like this:

But you've seen that computer systems have many more files stored which are hidden by default.

To view dotfiles in Finder, go to the root of your Home directory and hold down the keys Command Shift . and the same time.

You'll soon see a variety of dotfiles that either you created on your own or were created when you installed a piece of software.

To view dotfiles from the command line (which is where you'll use and interact with them the most), you again have to add some extra steps to your search.

The list command, ls, which lists all files and directories in the current directory, doesn't show dotfiles by default - despite the fact that they're there.

First, navigate to your home directory. You can use the cd command to help you get there, if you're not there already.

Then use the ls command with the -a flag, which stands for all, like so:

ls -a

If you want to see some extra bits of information about your files, you can also use the -l flag, which lists files and directories in long format and includes details about the date and time they were created, their size, and so on.

ls -la

In the output, you'll see all files and directories – inlcuding all hidden ones – in your currect home directory.

Each file and directory that starts with a period/dot is a dotfile.

Why Use Dotfiles?

Your dotfiles are personal to you.

You spend a sufficient amount of time fine-tuning your setup. You curate configurations and settings that best suit your workflow, aesthetic, and preferences. And you end up with a development environment that helps you, personally, be more productive.

What if after all that time you spent, you now have to switch to a new, different machine? Does that mean you have to start all over again from the beginning?

How would you remember the exact settings and commands you used?

Or what if you have a second machine and you want your set up to be exactly the same on both systems?

One of the main goals of developers is to automate repetitive tasks.

Creating a dotfile repository that is source-controlled and hosted on GitHub will save you time when you want to set up a new computer and install the exact same settings you created for your previous one.

That way all your settings and preferences can be reusable and consistent on other machines.

How to Create Dotfiles

How to set up a folder to hold your dotfiles

It's good practice to have all your dotfiles in their own folder.

For simplicity's sake, I'll show an example of how to create a folder at the root of your home directory. But you can add the folder wherever is more convenient for you.

Also, I'll be showing examples of how to create a .zshrc and .vimrc file, but similar ideas apply to any other dotfiles you create.

Navigate to your home directory (cd) and make a directory named dotfiles that will hold all your configuration files:

mkdir dotfiles

To create dotfiles, you use the touch command and pass the name(s) of the file(s) as the argument to the command. The filename(s) will have a preceding period.

To create a .zshrc and a .vimrc file in the dotfiles directory, do this:

touch ~/dotfiles/.zshrc  ~/dotfiles/.vimrc

If those files already exist on your system and you want to move them to the dotfiles directory, you can move them there using the mv command:

mv ~/.zshrc ~/dotfiles/

The first argument is the current path of the file – the tilde (~) stands for the home direcory. By default, most hidden confuguration files are located there.

The second argument is the path where you want to move the file to. In this case you want to move it to the the dotfiles directory that is located in the home directory.

You can do the same for the .vimrc file:

mv ~/.vimrc ~/dotfiles/

To view the files:

ls -a dotfiles 
.         ..     .vimrc    .zshrc

With those files in place you can then add all your preferred configurations there.

How to set up configurations

Below are some ideas that could help you start the configurations of the dotfiles you created.

How to personalise your Zsh prompt

After setting up the .zshrc file, anything added to that file will affect the customisation of your Zsh shell program.

Now could be the time to customise your shell prompt. This will be personal to your taste, but here are some resources to get you started:

• How to customize your zsh prompt like a pro
• Jazz up your zsh terminal in seven steps
• More ideas to customize the zsh prompt
• How to Customize the zsh Prompt in the macOS Terminal

How to customise Vim

After creating the .vimrc file, you can customise the command line text editor Vim. Here are a couple of resources to help you start that process:

• Vimrc Configuration Guide
• How to Make Vim Look Good: 5 Vim Customization Tips

What are aliases and functions

One way to improve your workflow and enhance your productivity, is to cut down the time it takes to type commands you use often. You can achieve that by creating shortcuts.

Aliases are shortcuts to terminal commands. They are a shorter version of a long command.

As a developer you'll use Git often, so it's a good idea to create Git aliases to help save time on long, repetitive Git commands. Have a read on some of the most helpful ones on this freeCodeCamp article.

Another way to save time is by simplifying processes.

You can combine two commands into one by creating an isolated behavior that does one specific job. You can do that by creating functions.

One helpful function to create is to combine the command for creating a new directory (mkdir) with the command to change directory (cd).

In this way, you will create a new folder and immediately change into it – all in one step.

The function to do so looks like this:

function mkcd() {
  mkdir -p "$@" && cd "$_";
}

To read up on Zsh, functions have a look at this article on Scripting OS X that covers both aliases and functions in Zsh.

You can add both aliases and functions to your .zshrc file or you can create separate .aliases and .functions dotfiles.

How to Symlink your Dotfiles

You may have noticed that none of the settings you added to the files in the dotfiles folder have any effect on your system.

A program's configuration files, as mentioned previously, are hidden and stored in the home directory by default. This is where the program will look for and read its settings from.

It's a good idea to symlink (or create a symbolic link -a pointer) the file in the dotfiles directory where you have stored your preferred settings alongside with other files you created, with the file in its default home directory.

It's like the file will be in two places at the same time!

The file will be in both the dotfiles directory and there will also be a 'copy' of it in the home directory.

To create a link, you use the ln (stands for link) command with the -s argument (which stands for symbolic).

Here's how to symlink the .zshrc and .vimrc files:

ln -s ~/dotfiles/.vimrc  ~/.vimrc
ln -s ~/dotfiles/.zshrc  ~/.zshrc

This will make the programs you use aware of where their configuration files are normally – back in the home directory.

ls -l ~/.zshrc 

lrwxr-xr-x  1 dionysialemonaki  staff  39 Oct 21 18:30 /Users/dionysialemonaki/.zshrc -> /Users/dionysialemonaki/dotfiles/.zshrc

Looking at the details of the .zshrc file, it shows that the file located in the home directory points to the file in the dotfiles directory. The -> indicates the symlink.

Symlinking all your dotfiles manually is a cumbersome process and can get tiring and repetitive quickly as you add more dotfiles to the folder.

To make the process easier, you can create a shell script that will automate calling ln -s on the dotfiles you create or use a utility for that job.

How to Version Control your Dotfiles

Having your files under version control will help you track all the changes you make to them over time, and will also allow you to share them on GitHub.

Make sure to change directory into the dotfiles directory (cd dotfiles).

Follow these steps to organise your files in a git repository:

1. Initialise the repository:

git init

2. Add all the files you've created so far:

git add .

3. Commit the changes and add a commit message:

git commit -m "Added dotfiles"

How to host your dotfiles on GitHub

Make sure you've signed into your GitHub account.

Then, create a new repository:

Give it a name add click "Create repository".

Next, in the command line, add:

git remote add origin url 

#where 'url',the GitHub url of the repository you previously created
#ending in .git

Finally,

git push -u origin main

And now you are able to share your dotfiles online!

Conclusion

And there you have it – you now know the basics of dotfiles! I hope you found this tutorial helpful.

Your dotfiles project will most likely follow you throughout your career and will grow the more you learn about dotfiles themselves. And it'll also change as you learn more about what you like and don't like regarding your workflow and development environment setting by lots of trial and error.

Thanks for reading!

When you're writing a shell script, you may find that you need it to wait a certain number of seconds before proceeding. For example, you might want the script to wait while a process completes or before retrying a failed command.

To do this, you can use the very straightforward sleep command.

How to Use the Bash Sleep Command

Sleep is a very versatile command with a very simple syntax. It is as easy as typing sleep N. This will pause your script for N seconds, with N being either a positive integer or a floating point number.

Consider this basic example:

echo "Hello there!"
sleep 2
echo "Oops! I fell asleep for a couple seconds!"

The result of this script will look like this:

Similarly, you could use a floating point number to represent fractions of seconds. For example, sleep .8 will pause your script for .8 seconds.

That's it for the basic usage of the sleep command!

What to Keep in Mind When Using the Sleep Command

Sleep's default unit of time is seconds, which is why we don't have to specify a unit in the examples above.

On some types of machines (namely BSD systems and MacOS,) the only unit of time supported is seconds. Other Unix-like operating systems will likely support the following units of time:

• s: seconds
• m: minutes
• h: hours
• d: days

It is also possible to use more than one argument with the sleep command. If there are two or more numbers included, the system will wait for the amount of time equivalent to the sum of those numbers.

For example, sleep 2m 30s will create a pause of 2 and a half minutes. Note that to achieve the same result on a MacOS or BSD machine, you would run the equivalent command sleep 150, as 2 minutes and 30 seconds is equal to 150 seconds.

Conclusion

The sleep command is a useful way to add pauses in your Bash script. Used in conjunction with other commands, sleep can help you create a timed alarm, run operations in the correct order, space out attempts to connect to a website, and more. So put this simple yet powerful tool in your Bash toolbox and code on!

Customizing your .bashrc file can greatly improve your workflow and increase your productivity.

The .bashrc is a standard file located in your Linux home directory. In this article I will show you useful .bashrc options, aliases, functions, and more.

The main benefits of configuring the .bashrc file are:

• Adding aliases allows you to type commands faster, saving you time.
• Adding functions allows you to save and rerun complex code.
• It displays useful system information.
• It customizes the Bash prompt.

How to Get Started with Editing .bashrc

Here's how you can edit the .bashrc file with a text editor:

$ vim ~/.bashrc

You can add date and time formatting to bash history.

HISTTIMEFORMAT="%F %T "

# Output

$ history
 1017  20210228 10:51:28  uptime
 1019  20210228 10:52:42  free -m
 1020  20210228 10:52:49  tree --dirsfirst -F
 1018  20210228 10:51:38  xrandr | awk '/\*/{print $1}'

Add this line to ignore duplicate commands in the history.

HISTCONTROL=ignoredups

To set the number of lines in active history and to set the number of lines saved in Bash history, add these two lines.

HISTSIZE=2000
HISTFILESIZE=2000

You can set your history to append instead of overwriting Bash history. shopt stands for "shell options".

shopt -s histappend

To see all the default shell options, run shopt -p.

# Output

$ shopt -p

shopt -u autocd                   
shopt -u assoc_expand_once        
shopt -u cdable_vars              
shopt -u cdspell                  
shopt -u checkhash                
shopt -u checkjobs                
shopt -s checkwinsize             
[...]

Create some variables to add color to the Bash prompt like this:

blk='\[\033[01;30m\]'   # Black
red='\[\033[01;31m\]'   # Red
grn='\[\033[01;32m\]'   # Green
ylw='\[\033[01;33m\]'   # Yellow
blu='\[\033[01;34m\]'   # Blue
pur='\[\033[01;35m\]'   # Purple
cyn='\[\033[01;36m\]'   # Cyan
wht='\[\033[01;37m\]'   # White
clr='\[\033[00m\]'      # Reset

This is for the Vim lovers. This will allow you to use vim commands on the command line. This is always the first line I add to my .bashrc.

set -o vi

How to Create Aliases in .bashrc

You can use aliases for commands you run a lot. Creating aliases will allow you to type faster, saving time and increasing productivity.

The syntax for creating an alias is alias <my_alias>='longer command'. To find out which commands would make good aliases, run this command to see a list of the top 10 commands you run most.

$ history | awk '{cmd[$2]++} END {for(elem in cmd) {print cmd[elem] " " elem}}' | sort -n -r | head -10

# Output

171 git
108 cd
62 vim
51 python3
38 history
32 exit
30 clear
28 tmux
28 tree
27 ls

Since I use Git a lot, that would be a great command to create an alias for.

# View Git status.
alias gs='git status'

# Add a file to Git.
alias ga='git add'

# Add all files to Git.
alias gaa='git add --all'

# Commit changes to the code.
alias gc='git commit'

# View the Git log.
alias gl='git log --oneline'

# Create a new Git branch and move to the new branch at the same time. 
alias gb='git checkout -b'

# View the difference.
alias gd='git diff'

Here are some other useful aliases:

# Move to the parent folder.
alias ..='cd ..;pwd'

# Move up two parent folders.
alias ...='cd ../..;pwd'

# Move up three parent folders.
alias ....='cd ../../..;pwd'

# Press c to clear the terminal screen.
alias c='clear'

# Press h to view the bash history.
alias h='history'

# Display the directory structure better.
alias tree='tree --dirsfirst -F'

# Make a directory and all parent directories with verbosity.
alias mkdir='mkdir -p -v'

# View the calender by typing the first three letters of the month.

alias jan='cal -m 01'
alias feb='cal -m 02'
alias mar='cal -m 03'
alias apr='cal -m 04'
alias may='cal -m 05'
alias jun='cal -m 06'
alias jul='cal -m 07'
alias aug='cal -m 08'
alias sep='cal -m 09'
alias oct='cal -m 10'
alias nov='cal -m 11'
alias dec='cal -m 12'

# Output

$ mar

     March 2021      
Su Mo Tu We Th Fr Sa 
    1  2  3  4  5  6 
 7  8  9 10 11 12 13 
14 15 16 17 18 19 20 
21 22 23 24 25 26 27 
28 29 30 31

How to Use Functions in .bashrc

Functions are great for more complicated code when an alias won't work.

Here's the basic function syntax:

function funct_name() {
    # code;
}

This is how you can find the largest files in a directory:

function find_largest_files() {
    du -h -x -s -- * | sort -r -h | head -20;
}

# Output

Downloads $ find_largest_files

709M    systemrescue-8.00-amd64.iso
337M    debian-10.8.0-amd64-netinst.iso
9.1M    weather-icons-master.zip
6.3M    Hack-font.zip
3.9M    city.list.json.gz
2.8M    dvdrental.tar
708K    IMG_2600.JPG
100K    sql_cheat_sheet_pgsql.pdf
4.0K    repeating-a-string.txt
4.0K    heart.svg
4.0K    Fedora-Workstation-33-1.2-x86_64-CHECKSUM
[...]

You can also add colors to the Bash prompt and display the current Git branch like this:

# Display the current Git branch in the Bash prompt.

function git_branch() {
    if [ -d .git ] ; then
        printf "%s" "($(git branch 2> /dev/null | awk '/\*/{print $2}'))";
    fi
}

# Set the prompt.

function bash_prompt(){
    PS1='${debian_chroot:+($debian_chroot)}'${blu}'$(git_branch)'${pur}' \W'${grn}' \$ '${clr}
}

bash_prompt

Custom Bash prompt

Grep (search) through your history for previous run commands:

function hg() {
    history | grep "$1";
}

# Output

$ hg vim

305  2021-03-02 16:47:33 vim .bashrc
307  2021-03-02 17:17:09 vim .tmux.conf

This is how you start a new project with Git:

function git_init() {
    if [ -z "$1" ]; then
        printf "%s\n" "Please provide a directory name.";
    else
        mkdir "$1";
        builtin cd "$1";
        pwd;
        git init;
        touch readme.md .gitignore LICENSE;
        echo "# $(basename $PWD)" >> readme.md
    fi
}

# Output

$ git_init my_project

/home/brandon/my_project
Initialized empty Git repository in /home/brandon/my_project/.git/

You can also get the weather report on the command line. This requires the package curl, jq, and an API key from Openweathermap. Read the Openweathermap API documentation in order to configure the URL correctly to get the weather in your location.

Install curl and jq with these commands:

$ sudo apt install curl jq

# OR

$ sudo dnf install curl jq

function weather_report() {

    local response=$(curl --silent 'https://api.openweathermap.org/data/2.5/weather?id=5128581&units=imperial&appid=<YOUR_API_KEY>') 

    local status=$(echo $response | jq -r '.cod')

    # Check for the 200 response indicating a successful API query.
    case $status in

        200) printf "Location: %s %s\n" "$(echo $response | jq '.name') $(echo $response | jq '.sys.country')"  
             printf "Forecast: %s\n" "$(echo $response | jq '.weather[].description')" 
             printf "Temperature: %.1f°F\n" "$(echo $response | jq '.main.temp')" 
             printf "Temp Min: %.1f°F\n" "$(echo $response | jq '.main.temp_min')" 
             printf "Temp Max: %.1f°F\n" "$(echo $response | jq '.main.temp_max')" 
            ;;
        401) echo "401 error"
            ;;
        *) echo "error"
            ;;

    esac

}

# Output

$ weather_report

Location: "New York" "US"
Forecast: "clear sky"
Temperature: 58.0°F
Temp Min: 56.0°F
Temp Max: 60.8°F

How to Print System Information in .bashrc

You can display useful system information when you open the terminal like this:

clear

printf "\n"
printf "   %s\n" "IP ADDR: $(curl ifconfig.me)"
printf "   %s\n" "USER: $(echo $USER)"
printf "   %s\n" "DATE: $(date)"
printf "   %s\n" "UPTIME: $(uptime -p)"
printf "   %s\n" "HOSTNAME: $(hostname -f)"
printf "   %s\n" "CPU: $(awk -F: '/model name/{print $2}' | head -1)"
printf "   %s\n" "KERNEL: $(uname -rms)"
printf "   %s\n" "PACKAGES: $(dpkg --get-selections | wc -l)"
printf "   %s\n" "RESOLUTION: $(xrandr | awk '/\*/{printf $1" "}')"
printf "   %s\n" "MEMORY: $(free -m -h | awk '/Mem/{print $3"/"$2}')"
printf "\n"

Output:

Source the .bashrc file to make the changes take effect:

$ source ~/.bashrc

Here are all these custom .bashrc settings together. On a new system I paste any customization below the default code in the .bashrc file.

######################################################################
#
#
#           ██████╗  █████╗ ███████╗██╗  ██╗██████╗  ██████╗
#           ██╔══██╗██╔══██╗██╔════╝██║  ██║██╔══██╗██╔════╝
#           ██████╔╝███████║███████╗███████║██████╔╝██║     
#           ██╔══██╗██╔══██║╚════██║██╔══██║██╔══██╗██║     
#           ██████╔╝██║  ██║███████║██║  ██║██║  ██║╚██████╗
#           ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═╝  ╚═╝╚═╝  ╚═╝ ╚═════╝
#
#
######################################################################

set -o vi

HISTTIMEFORMAT="%F %T "

HISTCONTROL=ignoredups

HISTSIZE=2000

HISTFILESIZE=2000

shopt -s histappend

blk='\[\033[01;30m\]'   # Black
red='\[\033[01;31m\]'   # Red
grn='\[\033[01;32m\]'   # Green
ylw='\[\033[01;33m\]'   # Yellow
blu='\[\033[01;34m\]'   # Blue
pur='\[\033[01;35m\]'   # Purple
cyn='\[\033[01;36m\]'   # Cyan
wht='\[\033[01;37m\]'   # White
clr='\[\033[00m\]'      # Reset

alias gs='git status'

alias ga='git add'

alias gaa='git add --all'

alias gc='git commit'

alias gl='git log --oneline'

alias gb='git checkout -b'

alias gd='git diff'

alias ..='cd ..;pwd'

alias ...='cd ../..;pwd'

alias ....='cd ../../..;pwd'

alias c='clear'

alias h='history'

alias tree='tree --dirsfirst -F'

alias mkdir='mkdir -p -v'

alias jan='cal -m 01'
alias feb='cal -m 02'
alias mar='cal -m 03'
alias apr='cal -m 04'
alias may='cal -m 05'
alias jun='cal -m 06'
alias jul='cal -m 07'
alias aug='cal -m 08'
alias sep='cal -m 09'
alias oct='cal -m 10'
alias nov='cal -m 11'
alias dec='cal -m 12'

function hg() {
    history | grep "$1";
}

function find_largest_files() {
    du -h -x -s -- * | sort -r -h | head -20;
}

function git_branch() {
    if [ -d .git ] ; then
        printf "%s" "($(git branch 2> /dev/null | awk '/\*/{print $2}'))";
    fi
}

# Set the prompt.
function bash_prompt(){
    PS1='${debian_chroot:+($debian_chroot)}'${blu}'$(git_branch)'${pur}' \W'${grn}' \$ '${clr}
}

bash_prompt

function git_init() {
    if [ -z "$1" ]; then
        printf "%s\n" "Please provide a directory name.";
    else
        mkdir "$1";
        builtin cd "$1";
        pwd;
        git init;
        touch readme.md .gitignore LICENSE;
        echo "# $(basename $PWD)" >> readme.md
    fi
}

function weather_report() {

    local response=$(curl --silent 'https://api.openweathermap.org/data/2.5/weather?id=5128581&units=imperial&appid=<YOUR_API_KEY>') 

    local status=$(echo $response | jq -r '.cod')

    case $status in

        200) printf "Location: %s %s\n" "$(echo $response | jq '.name') $(echo $response | jq '.sys.country')"  
             printf "Forecast: %s\n" "$(echo $response | jq '.weather[].description')" 
             printf "Temperature: %.1f°F\n" "$(echo $response | jq '.main.temp')" 
             printf "Temp Min: %.1f°F\n" "$(echo $response | jq '.main.temp_min')" 
             printf "Temp Max: %.1f°F\n" "$(echo $response | jq '.main.temp_max')" 
            ;;
        401) echo "401 error"
            ;;
        *) echo "error"
            ;;

    esac

}

clear

printf "\n"
printf "   %s\n" "IP ADDR: $(curl ifconfig.me)"
printf "   %s\n" "USER: $(echo $USER)"
printf "   %s\n" "DATE: $(date)"
printf "   %s\n" "UPTIME: $(uptime -p)"
printf "   %s\n" "HOSTNAME: $(hostname -f)"
printf "   %s\n" "CPU: $(awk -F: '/model name/{print $2}' | head -1)"
printf "   %s\n" "KERNEL: $(uname -rms)"
printf "   %s\n" "PACKAGES: $(dpkg --get-selections | wc -l)"
printf "   %s\n" "RESOLUTION: $(xrandr | awk '/\*/{printf $1" "}')"
printf "   %s\n" "MEMORY: $(free -m -h | awk '/Mem/{print $3"/"$2}')"
printf "\n"

Conclusion

In this article you learned how to configure various .bashrc options, aliases, functions, and more to greatly improve your workflow and increase your productivity.

Follow me on Github | Dev.to.

How to create it

Create the file:

$ touch myscript.sh

Add a shebang at the start of the file. The Shebang line is responsible for letting the command interpreter know which interpreter the shell script will be run with:

$ echo "#!/bin/bash" > myscript.sh
# or
$ your-desired-editor myscript.sh
# write at the first line #!/bin/bash

Add some commands:

$ echo "echo Hello World!" >> myscript.sh

Give the file execution mode:

$ chmod +x myscript.sh

Execute it!

$ ./myscript.sh
Hello World!

More info about shell-scripting can be found here

More info on shell scripting and Linux:

• A beginner's guide to surviving in the Linux shell
• Basic Linux commands to know
• Shell scripting tricks

Just so this doesn’t all go completely madcap, you ought to make some gift lists. Bash can help.

Brace expansion

These are not braces: ()

Neither are these: []

These are braces: {}

Braces tell Bash to do something with the arbitrary string or strings it finds between them. Multiple strings are comma-separated: {a,b,c}. You can also add an optional preamble and postscript to be attached to each expanded result. Mostly, this can save some typing, such as with common file paths and extensions.

Let’s make some lists for each person we want to give stuff to. The following commands are equivalent:

touch /home/me/gift-lists/Amy.txt /home/me/gift-lists/Bryan.txt /home/me/gift-lists/Charlie.txt

touch /home/me/gift-lists/{Amy,Bryan,Charlie}.txt

tree gift-lists

/home/me/gift-lists
├── Amy.txt
├── Bryan.txt
└── Charlie.txt

Oh darn, “Bryan” spells his name with an “i.” I can fix that.

mv /home/me/gift-lists/{Bryan,Brian}.txt

renamed '/home/me/gift-lists/Bryan.txt' -> '/home/me/gift-lists/Brian.txt'

Shell parameter expansions

Shell parameter expansion allows us to make all sorts of changes to parameters enclosed in braces, like manipulate and substitute text.

There are a few stocking stuffers that all our giftees deserve. Let’s make that a variable:

STUFF=$'socks\nlump of coal\nwhite chocolate'

echo "$STUFF"
socks
lump of coal
white chocolate

Now to add these items to each of our lists with some help from the tee command to get echo and expansions to play nice.

echo "$STUFF" | tee {Amy,Brian,Charlie}.txt

cat {Amy,Brian,Charlie}.txt

socks
lump of coal
white chocolate
socks
lump of coal
white chocolate
socks
lump of coal
white chocolate

Pattern match substitution

On second thought, maybe the lump of coal isn’t such a nice gift. You can replace it with something better using a pattern match substitution in the form of ${parameter/pattern/string}:

echo "${STUFF/lump of coal/candy cane}" | tee {Amy,Brian,Charlie}.txt

cat {Amy,Brian,Charlie}.txt

socks
candy cane
white chocolate
socks
candy cane
white chocolate
socks
candy cane
white chocolate

This replaces the first instance of “lump of coal” with “candy cane.” To replace all instances (if there were multiple), use ${parameter//pattern/string}. This doesn’t change our $STUFF variable, so we can still reuse the original list for someone naughty later.

Substrings

While we’re improving things, our giftees may not all like white chocolate. We’d better add some regular chocolate to our lists just in case. Since I’m super lazy, I’m just going to hit the up arrow and modify a previous Bash command. Luckily, the last word in the $STUFF variable is “chocolate,” which is nine characters long, so I’ll tell Bash to keep just that part using ${parameter:offset}. I’ll use tee’s -a flag to append to my existing lists:

echo "${STUFF: -9}" | tee -a {Amy,Brian,Charlie}.txt

cat {Amy,Brian,Charlie}.txt

socks
candy cane
white chocolate
chocolate
socks
candy cane
white chocolate
chocolate
socks
candy cane
white chocolate
chocolate

You can also:

There! Now our base lists are finished. Let’s have some eggnog.

Testing variables

You know, it may be the eggnog, but I think I started a list for Amy yesterday and stored it in a variable that I might have called amy. Let’s see if I did. I’ll use the ${parameter:?word} expansion. It’ll write word to standard error and exit if there’s no amy parameter.

echo "${amy:?no such}"

bash: amy: no such

I guess not. Maybe it was Brian instead?

echo "${brian:?no such}"

Lederhosen

You can also:

Changing case

That’s right! Brian said he wanted some lederhosen and so I made myself a note. This is pretty important, so I’ll add it to Brian’s list in capital letters with the ${parameter^^pattern} expansion. The pattern part is optional. We’re only writing to Brian’s list, so I’ll just use >> instead of tee -a.

echo "${brian^^}" >> Brian.txt

cat Brian.txt

socks
candy cane
white chocolate
chocolate
LEDERHOSEN

You can also:

Expanding arrays

You know what, all this gift-listing business is a lot of work. I’m just going to make an array of things I saw at the store:

gifts=(sweater gameboy wagon pillows chestnuts hairbrush)

I can use substring expansion in the form of ${parameter:offset:length} to make this simple. I’ll add the first two to Amy’s list, the middle two to Brian’s, and the last two to Charlie’s. I’ll use printf to help with newlines.

printf '%s\n' "${gifts[@]:0:2}" >> Amy.txt
printf '%s\n' "${gifts[@]:2:2}" >> Brian.txt
printf '%s\n' "${gifts[@]: -2}" >> Charlie.txt

cat Amy.txt

socks
candy cane
white chocolate
chocolate
sweater
gameboy

cat Brian.txt

socks
candy cane
white chocolate
chocolate
LEDERHOSEN
wagon
pillows

cat Charlie.txt

socks
candy cane
white chocolate
chocolate
chestnuts
hairbrush

There! Now we’ve got a comprehensive set of super personalized gift lists. Thanks Bash! Too bad it can’t do the shopping for us, too.

With the general availability of GitHub Actions, we have a chance to programmatically access and preserve GitHub event data in our repository. Making the data part of the repository itself is a way of preserving it outside of GitHub. It also gives us the ability to feature the data on a front-facing website, such as with GitHub Pages.

And, if you’re like me, you can turn GitHub issue comments into an awesome 90s guestbook page.

No matter the usage, the principle concepts are the same. We can use Actions to access, preserve, and display GitHub event data - with just one workflow file. To illustrate the process, I’ll take you through the workflow code that makes my guestbook shine on.

For an introductory look at GitHub Actions including how workflows are triggered, see A lightweight, tool-agnostic CI/CD flow with GitHub Actions.

Accessing GitHub event data

An Action workflow runs in an environment with some default environment variables. A lot of convenient information is available here, including event data. The most complete way to access the event data is using the $GITHUB_EVENT_PATH variable, the path of the file with the complete JSON event payload.

The expanded path looks like /home/runner/work/_temp/_github_workflow/event.json and its data corresponds to its webhook event. You can find the documentation for webhook event data in GitHub REST API Event Types and Payloads. To make the JSON data available in the workflow environment, you can use a tool like jq to parse the event data and put it in an environment variable.

Below, I grab the comment ID from an issue comment event:

ID="$(jq '.comment.id' $GITHUB_EVENT_PATH)"

Most event data is also available via the github.event context variable without needing to parse JSON. The fields are accessed using dot notation, as in the example below where I grab the same comment ID:

ID=${{ github.event.comment.id }}

For my guestbook, I want to display entries with the user’s handle, and the date and time. I can capture this event data like so:

AUTHOR=${{ github.event.comment.user.login }}
DATE=${{ github.event.comment.created_at }}

Shell variables are handy for accessing data, however, they’re ephemeral. The workflow environment is created anew each run, and even shell variables set in one step do not persist to other steps. To persist the captured data, you have two options: use artifacts, or commit it to the repository.

Preserving event data: using artifacts

Using artifacts, you can persist data between workflow jobs without committing it to your repository. This is handy when, for example, you wish to transform or incorporate the data before putting it somewhere more permanent. It’s necessary to persist data between workflow jobs because:

Each job in a workflow runs in a fresh instance of the virtual environment. When the job completes, the runner terminates and deletes the instance of the virtual environment. (Persisting workflow data using artifacts)

Two actions assist with using artifacts: upload-artifact and download-artifact. You can use these actions to make files available to other jobs in the same workflow. For a full example, see passing data between jobs in a workflow.

The upload-artifact action’s action.yml contains an explanation of the keywords. The uploaded files are saved in .zip format. Another job in the same workflow run can use the download-artifact action to utilize the data in another step.

You can also manually download the archive on the workflow run page, under the repository’s Actions tab.

Persisting workflow data between jobs does not make any changes to the repository files, as the artifacts generated live only in the workflow environment.

Personally, being comfortable working in a shell environment, I see a narrow use case for artifacts, though I’d have been remiss not to mention them. Besides passing data between jobs, they could be useful for creating .zip format archives of, say, test output data. In the case of my guestbook example, I simply ran all the necessary steps in one job, negating any need for passing data between jobs.

Preserving event data: pushing workflow files to the repository

To preserve data captured in the workflow in the repository itself, it is necessary to add and push this data to the Git repository. You can do this in the workflow by creating new files with the data, or by appending data to existing files, using shell commands.

Creating files in the workflow

To work with the repository files in the workflow, use the checkout action to first get a copy to work with:

- uses: actions/checkout@master
  with:
    fetch-depth: 1

To add comments to my guestbook, I turn the event data captured in shell variables into proper files, using substitutions in shell parameter expansion to sanitize user input and translate newlines to paragraphs. I wrote previously about why user input should be treated carefully.

- name: Turn comment into file
  run: |
    ID=${{ github.event.comment.id }}
    AUTHOR=${{ github.event.comment.user.login }}
    DATE=${{ github.event.comment.created_at }}
    COMMENT=$(echo "${{ github.event.comment.body }}")
    NO_TAGS=${COMMENT//[<>]/\`}
    FOLDER=comments

    printf '%b\n' "<div class=\"comment\"><p>${AUTHOR} says:</p><p>${NO_TAGS//$'\n'/\<\/p\>\<p\>}</p><p>${DATE}</p></div>\r\n" > ${FOLDER}/${ID}.html

By using printf and directing its output with > to a new file, the event data is transformed into an HTML file, named with the comment ID number, that contains the captured event data. Formatted, it looks like:

<div class="comment">
  <p>victoriadrake says:</p>
  <p>This is a comment!</p>
  <p>2019-11-04T00:28:36Z</p>
</div>

When working with comments, one effect of naming files using the comment ID is that a new file with the same ID will overwrite the previous. This is handy for a guestbook, as it allows any edits to a comment to replace the original comment file.

If you’re using a static site generator like Hugo, you could build a Markdown format file, stick it in your content/ folder, and the regular site build will take care of the rest.

In the case of my simplistic guestbook, I have an extra step to consolidate the individual comment files into a page. Each time it runs, it overwrites the existing index.html with the header.html portion (>), then finds and appends (>>) all the comment files’ contents in descending order, and lastly appends the footer.html portion to end the page.

- name: Assemble page
  run: |
    cat header.html > index.html
    find comments/ -name "*.html" | sort -r | xargs -I % cat % >> index.html
    cat footer.html >> index.html

Committing changes to the repository

Since the checkout action is not quite the same as cloning the repository, at time of writing, there are some issues still to work around. A couple extra steps are necessary to pull, checkout, and successfully push changes back to the master branch, but this is pretty trivially done in the shell.

Below is the step that adds, commits, and pushes changes made by the workflow back to the repository’s master branch.

- name: Push changes to repo
  run: |
    REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}
    git config user.email "${{ github.actor }}@users.noreply.github.com"
    git config user.name "${{ github.actor }}"

    git pull ${REMOTE}
    git checkout master
    git add .
    git status
    git commit -am "Add new comment"
    git push ${REMOTE} master

The remote, in fact, our repository, is specified using the github.repository context variable. For our workflow to be allowed to push to master, we use the secrets.GITHUB_TOKEN variable.

Since the workflow environment is shiny and newborn, we need to configure Git. In the above example, I’ve used the github.actor context variable to input the username of the account initiating the workflow. The email is similarly configured using the default noreply GitHub email address.

Displaying event data

Nov 6, 2019 correction: GitHub Actions requires a Personal Access Token to trigger a Pages site build.

If you're using GitHub Pages with the default secrets.GITHUB_TOKEN variable and without a site generator, pushing changes to the repository in the workflow will only update the repository files. The GitHub Pages build will fail with an error, "Your site is having problems building: Page build failed."

To enable Actions to trigger a Pages site build, you'll need to create a Personal Access Token. This token can be stored as a secret in the repository settings and passed into the workflow in place of the default secrets.GITHUB_TOKEN variable. I wrote more about Actions environment and variables in this post.

With the use of a Personal Access Token, a push initiated by the Actions workflow will also update the Pages site. You can see it for yourself by leaving a comment in my guestbook! The comment creation event triggers the workflow, which then takes around 30 seconds to a minute to run and update the guestbook page.

Where a site build is necessary for changes to be published, such as when using Hugo, an Action can do this too. However, in order to avoid creating unintended loops, one Action workflow will not trigger another. Instead, it's extremely convenient to handle the process of building the site with a Makefile, which any workflow can then run. Simply add running the Makefile as the final step in your workflow job, with the repository token where necessary:

- name: Run Makefile
  env:
    TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: make all

This ensures that the final step of your workflow builds and deploys the updated site.

No more event data horizon

GitHub Actions provides a neat way to capture and utilize event data so that it’s not only available within GitHub. The possibilities are only as limited as your imagination! Here are a few ideas for things this lets us create:

1. A public-facing issues board, where customers without GitHub accounts can view and give feedback on project issues.
2. An automatically-updating RSS feed of new issues, comments, or PRs for any repository.
3. A comments system for static sites, utilizing GitHub issue comments as an input method.
4. An awesome 90s guestbook page.

Did I mention I made a 90s guestbook page? My inner-Geocities-nerd is a little excited.

I recently came across a few such things, particularly in Tom Hudson’s dotfiles. Tom seems to like to script things, and some of those things include automatically setting up symlinks, and installing Ubuntu repository applications and other programs. This got me thinking. Could I automate the set up of a new machine to replicate my current one?

Being someone generally inclined to take things apart in order to see how they work, I know I’ve messed up my laptop on occasion. (Usually when I’m away from home, and my backup harddrive isn’t.) On those rare but really inconvenient situations when my computer becomes a shell of its former self, (ba-dum-ching) it’d be quite nice to have a fast, simple way of putting Humpty Dumpty back together again, just the way I like.

In contrast to creating a disk image and restoring it later, a collection of bash scripts is easier to create, maintain, and move around. They require no special utilities, only an external transportation method. It’s like passing along the recipe, instead of the whole bundt cake. (Mmm, cake.)

Additionally, functionality like this would be super useful when setting up a virtual machine, or VM, or even just a virtual private server, or VPS. (Both of which, now that I write this, would probably make more forgiving targets for my more destructive experimentations… live and learn!)

Well, after some grepping and Googling and digging around, I now have a suite of scripts that can do this:

See a video of the setup here.

This is the tail end of a test run of the set up scripts on a fresh Ubuntu desktop, loaded off a bootable USB. It had all my programs and settings restored in under three minutes!

This post will cover how to achieve the automatic set up of a computer running Ubuntu Desktop (in my case, Ubuntu LTS 18.04) using bash scripts. The majority of the information covered is applicable to all the Linux desktop flavours, though some syntax may differ. The bash scripts cover three main areas: linking dotfiles, installing software from Ubuntu and elsewhere, and setting up the desktop environment. We’ll cover each of these areas and go over the important bits so that you can begin to craft your own scripts.

Dotfiles

Dotfiles are what most Linux enthusiasts call configuration files. They typically live in the user’s home directory (denoted in bash scripts with the builtin variable $HOME) and control the appearance and behaviour of all kinds of programs. The file names begin with ., which denotes hidden files in Linux (hence “dot” files). Here are some common dotfiles and ways in which they’re useful.

.bashrc

The .bashrc file is a list of commands executed at startup by interactive, non-login shells. Interactive vs non-interactive shells can be a little confusing, but aren’t necessary for us to worry about here. For our purposes, any time you open a new terminal, see a prompt, and can type commands into it, your .bashrc was executed.

Lines in this file can help improve your workflow by creating aliases that reduce keystrokes, or by displaying a helpful prompt with useful information. It can even run user-created programs, like Eddie. For more ideas, you can have a look at my .bashrc file on GitHub.

.vimrc

The .vimrc dotfile configures the champion of all text editors, Vim. (If you haven’t yet wielded the powers of the keyboard shortcuts, I highly recommend a fun game to learn Vim with.)

In .vimrc, we can set editor preferences such as display settings, colours, and custom keyboard shortcuts. You can take a look at my .vimrc on GitHub.

Other dotfiles may be useful depending on the programs you use, such as .gitconfig or .tmux.conf. Exploring dotfiles on GitHub is a great way to get a sense of what’s available and useful to you!

Linking dotfiles

We can use a script to create symbolic links, or symlinks for all our dotfiles. This allows us to keep all the files in a central repository, where they can easily be managed, while also providing a sort of placeholder in the spot that our programs expect the configuration file to be found. This is typically, but not always, the user home directory. For example, since I store my dotfiles on GitHub, I keep them in a directory with a path like ~/github/dotfiles/ while the files themselves are symlinked, resulting in a path like ~/.vimrc.

To programmatically check for and handle any existing files and symlinks, then create new ones, we can use this elegant shell script. I compliment it only because I blatantly stole the core of it from Tom’s setup script, so I can’t take the credit for how lovely it is.

The symlink.sh script works by attempting to create symlinks for each dotfile in our $HOME. It first checks to see if a symlink already exists, or if a regular file or directory with the same name exists. In the former case, the symlink is removed and remade; in the latter, the file or directory is renamed, then the symlink is made.

Installing software

One of the beautiful things about exploring shell scripts is discovering how much can be achieved using only the command line. As someone whose first exposure to computers was through a graphical operating system, I find working in the terminal to be refreshingly fast.

With Ubuntu, most programs we likely require are available through the default Ubuntu software repositories. We typically search for these with the command apt search <program> and install them with sudo apt install <program>. Some software we’d like may not be in the default repositories, or may not be offered there in the most current version. In these cases, we can still install these programs in Ubuntu using a PPA, or Personal Package Archive. We’ll just have to be careful that the PPAs we choose are from the official sources.

If a program we’d like doesn’t appear in the default repositories or doesn’t seem to have a PPA, we may still be able to install it via command line. A quick search for “installation command line” should get some answers.

Since bash scripts are just a collection of commands that we could run individually in the terminal, creating a script to install all our desired programs is as straightforward as putting all the commands into a script file. I chose to organize my installation scripts between the default repositories, which are installed by my aptinstall.sh script, and programs that involve external sources, handled with my programs.sh script.

Setting up the desktop environment

On the recent occasions when I’ve gotten a fresh desktop (intentionally or otherwise) I always seem to forget how long it takes to remember, find, and then change all the desktop environment settings. Keyboard shortcuts, workspaces, sound settings, night mode… it adds up!

Thankfully, all these settings have to be stored somewhere in a non-graphical format, which means that if we can discover how that’s done, we can likely find a way to easily manipulate the settings with a bash script. Lo and behold the terminal command, gsettings list-recursively.

There are a heck of a lot of settings for GNOME desktop environment. We can make the list easier to scroll through (if, like me, you’re sometimes the type of person to say “Just let me look at everything and figure out what I want!”) by piping to less: gsettings list-recursively | less. Alternatively, if we have an inkling as to what we might be looking for, we can use grep: gsettings list-recursively | grep 'keyboard'.

We can manipulate our settings with the gsettings set command. It can sometimes be difficult to find the syntax for the setting we want, so when we’re first building our script, I recommend using the GUI to make the changes, then finding the gsettings line we changed and recording its value.

For some inspiration, you can view my desktop.sh settings script on GitHub.

Putting it all together

Having modular scripts (one for symlinks, two for installing programs, another for desktop settings) is useful for both keeping things organized and for being able to run some but not all of the automated set up. For instance, if I were to set up a VPS in which I only use the command line, I wouldn’t need to bother with installing graphical programs or desktop settings.

In cases where I do want to run all the scripts, however, doing so one-by-one is a little tedious. Thankfully, since bash scripts can themselves be run by terminal commands, we can simply write another master script to run them all!

Here’s my master script to handle the set up of a new Ubuntu desktop machine:

#!/bin/bash

./symlink.sh
./aptinstall.sh
./programs.sh
./desktop.sh

# Get all upgrades
sudo apt upgrade -y

# See our bash changes
source ~/.bashrc

# Fun hello
figlet "... and we're back!" | lolcat

I threw in the upgrade line for good measure. It will make sure that the programs installed on our fresh desktop have the latest updates. Now a simple, single bash command will take care of everything!

You may have noticed that, while our desktop now looks and runs familiarly, these scripts don’t cover one very important area: our files. Hopefully, you have a back up method for those that involves some form of reliable external hardware. If not, and if you tend to put your work in external repository hosts like GitHub or GitLab, I do have a way to automatically clone and back up your GitHub repositories with bash one-liners.

Relying on external repository hosts doesn’t offer 100% coverage, however. Files that you wouldn’t put in an externally hosted repository (private or otherwise) consequently can’t be pulled. Git ignored objects that can’t be generated from included files, like private keys and secrets, will not be recreated. Those files, however, are likely small enough that you could fit a whole bunch on a couple encrypted USB flash drives (and if you don’t have private key backups, maybe you ought to do that first?).

That said, I hope this post has given you at least some inspiration as to how dotfiles and bash scripts can help to automate setting up a fresh desktop. If you come up with some settings you find useful, please help others discover them by sharing your dotfiles, too!

Shell scripts vs python or Perl

It's 2020 now, who writes shell scripts anymore? Am I right? Well, apparently I do. ¯_(ツ)_/¯

There are some good arguments for that here and here which mainly revolve around 2 things:

1. Shell exists in all Unix systems and makes use of system default features.
2. Shell is an “interactive command function” designed to get user inputs during the process of running them.

Also, here’s an additional relevant reading about the differences between sh and bash.

Arguments

In some occasions, you will need to pass an argument (or expect one) into the script like how you might pass a param into a function. In that case, you will use something like $1 for the first argument, $2 for the second. Here's an example of how it would look like:

In script run_this.sh:

echo "The input message was $1."

Running the command:

./run_this.sh userInputThe input message was userInput.

_Note: The params are separated by spaces so if you want to input a string as a param that contains a space, it might need to be something like ./run_this.sh "user input" just so "user input" would be counted as $1 entirely._

In the occasion where you are not sure how long the user input might be and you want to capture it all, you would use $@ instead. In the following example, I took in the entire string and print it out word by word after breaking them into a string array according to the spaces in between.

In script run_this.sh:

userInputs=($@)for i in "${userInputs[@]}";; do  echo "$i"done

Running the command:

./run_this.sh who knows how long this can gowhoknowshowlongthiscango

Functions

If you have done any sort of programming, you should be familiar with the concept of functions. It's basically a set of commands / operations that you will be repeating over and over again. Instead of repeating it multiple times in your code, you can put them into a function. Then just call the function which effectively reduces the lines of code that need to be written.

Side note: If you don’t know already, LOC is a horrible metric for any sort of measurement in terms of programming. Don’t take this from me, take this from Bill Gates:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

Here’s how a normal function looks like:

# Declaring the functiondoSomething() {

}

# Calling the functiondoSomething

Pretty straightforward and easy to understand. Now, here are a few differences between functions in shell scripts and a normal programming language.

Parameters

If you were to pass a parameter / use a parameter into a function in Java, you have to declare them in the function declaration. They look something like this.

public static void main(String[] args) {    doSomething("random String");}

private static void doSomething (String words) {    System.out.println(words);}

In the shell, however, they do not require a declaration of types or names at all. Each of them is like a separate script that lives in the script itself. If you were to use a param, just pass it in and call it like how you would do it if you were taking in input for this script at the top level. Something like this:

doSomething() {    echo $1}

doSomething "random String"

1. Similar to above, if you want to take in everything, you will use $@ instead of $1 since $1 would only use the first input (and $2 for the second etc.).
2. Functions need to be declared ahead of where they are being called. (Usually beginning of the file before any main operations.)

Return

Let’s say we create a script like below named run_this.sh:

doSomething() {    echo "magic"    return 0}

output=`doSomething`echo $output

Now let’s run it and see what is being assigned to the output variable.

$ ./run_this.shmagic

Note that instead of 0, it shows magic instead. This is because when you do output=doSomething`, it assigns the output message tooutput` instead of the return value since the output message is how you communicate almost anything in the shell script.

So when does it make sense to use the return call? When you are using it as part of an if statement. Something like this:

In script run_this.sh:

doSomething() {    echo "magic"    return 0}

if doSomething; then    echo "Its true!"fi

Running the command:

./run_this.shIts true!

In this case, return 0 means true while return 1 meant false in a traditional boolean sense.

Multi-line echo

There are times when you need to print a multi-line message. There are a few ways to go around this. The easiest way is to use echo multiple times like this:

echo "line1"echo "line2"echo "line3"

It works but probably not the most elegant way to get around this. Instead, you can use cat <&lt; EOF instead. Something like this:

cat << EOFline1line2line3EOF

Note that there should not be anything (including spaces or tabs) before EOF. If you want to do it in an ifstatement, it should look something like this.

if [ "a" == "a" ]; then  cat << EOFline1line2line3EOFfi

Realize that even the messages themselves are aligned to the left. This is because if you leave them tabbed, the output message shown in the command line will also be tabbed. Also, if EOF is tabbed, the shell will complain about it and usually ends the script there.

Flags / Options

You’ve probably seen some of the scripts or commands that comes with an ability to add flags (and sometimes arguments for the specific flag). Something like git commit -a -m "Some commit message".

Here’s a quick example of how it looks like (I’ve tried to be as comprehensive as possible with the example.)

In script run_this.sh:

while getopts ac: opt; do    case $opt in        a)            echo "\"a\" was executed."            ;;        c)            echo "\"c\" was executed with parameter \"$OPTARG\"."            ;;        \?)            echo "Invalid option: -$opt"            exit 1            ;;        :)            echo "option -$opt requires an argument."            exit 1            ;;    esacdone

Running the command:

./run_this.sh

./run_this.sh -a"a" was executed.

./run_this.sh -coption -c requires an argument.

./run_this.sh -c abcd"c" was executed with parameter "abcd".

./run_this.sh -a -c abc"a" was executed."c" was executed with parameter "abc".

./run_this.sh -xInvalid option: -x

In the above example, the differences between option -a and -c is that in the getopts line, c has a colon (:) following it after therefore telling the program to expect a parameter for the option. Another thing to keep in mind is that the options need to be declared in an alphabetical way. If you declare something like acb, the bdeclaration would be ignored, and using the -b flag would lead to the error message instead of the b case in the switch condition.

Thanks for reading!

About me

I currently work at Facebook as a Software Engineer. I spend some of my free time experimenting and building new things with technologies I find fun and interesting. Follow my exploration journey here or on GitHub.

References

• Small getopts tutorial
• How to output a multiline string in Bash