Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions docs/books/learning_bash/00-toc.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
---
title: Learning bash with Rocky
---

# Learning Bash with Rocky

In this part, you will learn more about Bash scripting, an exercise that every administrator will have to perform one day or another.

## Generalities

The shell is the command interpreter of Linux.
It is a binary that is not part of the kernel, but forms an additional layer, hence its name "shell".

It parses the commands entered by the user and then makes them executed by the system.

There are several shells, all of which share some common features.
The user is free to use the one that suits him best among (among others):

* the **Bourne-Again shell** (`bash`),
* the **Korn shell** (`ksh`),
* the **C shell** (`csh`),
* etc.

The `bash` is present by default on the main Linux distributions.
It is characterized by its practical and user-friendly features.

The shell is also a **basic programming language** which, thanks to some dedicated commands, allows :

* the use of **variables**,
* **conditional execution** of commands,
* the **repetition** of commands.

Shell scripts have the advantage that they can be created **quickly** and **reliably**, without **compiling** or installing additional commands. A shell script is just a text file without any embellishments (bold, italics, etc.).

!!! NOTE

Although the shell is a "basic" programming language, it is still very powerful and sometimes faster than bad compiled code.

To write a shell script, you just have to put all the necessary commands in a single text file.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also call other scripts from within to make a single script less cumbersome and easier to understand.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, basically you need a file and the commands in it to make it work. This is an introduction, keep it simple.
If I add "at least" or something like that.

By making this file executable, the shell will read it sequentially and execute the commands in it one by one.
It is also possible to execute it by passing the name of the script as an argument to the bash binary.

When the shell encounters an error, it displays a message to identify the problem but continues to execute the script.
But there are mechanisms to stop the execution of a script when an error occurs.
Command-specific errors are also displayed on the screen or inside files.

What is a good script? It is:

* **reliable**: its operation is flawless even in case of misuse;
* **commented**: its code is annotated to facilitate the rereading and the future evolutions;
* **readable**: the code is indented appropriately, the commands are spaced out, ...
* **portable**: the code runs on any Linux system, dependency management, rights management, etc.
109 changes: 109 additions & 0 deletions docs/books/learning_bash/01-first-script.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
---
title: Bash - First script
author: Antoine Le Morvan
contributors: Steven Spencer
update: 29-mar-2022
---

# Bash - First script

In this chapter you will learn how to write your first script in bash.

****

**Objectives**: In this chapter you will learn how to:

:heavy_check_mark: Write your first script in bash;
:heavy_check_mark: Execute your first script;
:heavy_check_mark: Specify which shell to use with the so-called shebang;

:checkered_flag: **linux**, **script**, **bash**

**Knowledge**: :star:
**Complexity**: :star:

**Reading time**: 10 minutes

****

## My first script

To start writing a shell script, it is convenient to use a text editor that supports syntax highlighting.

`vim`, for example, is a good tool for this.

The name of the script should respect some rules:

* no names of existing commands;
* only alphanumeric characters, i.e. no accented characters or spaces;
* extension .sh to indicate that it is a shell script.

```
#!/usr/bin/env bash
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never had to use the shebang this way. For instance, all of my bash scripts represent the path to bash which on my workstation is /usr/bin/bash... The shebang that I would use is #!/usr/bin/bash ... I'm not saying this way is wrong, I've just not seen it before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes me too. I have always put #!/bin/bash.
In the case of python for example,
#!/usr/bin/env python will use the python version defined by alternative.
I have read that it's good to do this, because it does not matter of the path to bash (in your case #!/usr/bin/bash)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using env in the shebang line has been around a long time, and was designed to allow scripts to work portably on nix's that had executables in alternate dirs (like /usr/local/bin, /opt/bin, etc). Like many "improvements" regarding abstraction it didn't really catch on and many devs/admins never even knew about it, another classic example is using "info" rather than "man", or surrounding program calls in scripts with parenthesis (for security). Later, others who either were unaware of, or just dissagreed with this method developed other solutions like alternatives, "environment-modules", and "direnv", while some devs devised specific program solutions like python's "virtualenv" and "anaconda" etc. env has been the std for a very long time, but was primarily used to temporarily alter environment settings to pass to autotools utils like configure, as well as gcc. The bottom line is that what you use for shebang depends on what the system admins implement systemwide, and/or per user and sadly there is currently no real "best-practice" in any universal sense because there is so much variance in system setup techniques, but using env has gained some traction and offers the most flexibility for admins and users. I have used it in the shebang for 15 or so years and not had any major issues, however I was the admin for all the systems I used and set things up so that there would be consistency among the various elements (alternatives, environment-modules, $PATH, /etc/skel/ , etc)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey thanks @NezSez for this explanation!
The review is really a good thing 👍

#
# Author : Rocky Documentation Team
# Date: March 2022
# Version 1.0.0: Displays the text "Hello world!"
#

# Displays a text on the screen :
echo "Hello world!"
```

To be able to run this script, as an argument to bash:

```
$ bash hello-world.sh
Hello world !
```

Or, more simply, after having given it the right to execute:

```
$ chmod u+x ./hello-world.sh
$ ./hello-world.sh
Hello world !
```

!!! NOTE

Note that to execute the script, it has been called with `./` before its name.
The interpreter may refuse to execute a script present in the current directory without indicating a path (here with `./` before it).

The `chmod` command is to be passed only once on a newly created script.

The first line to be written in any script is to indicate the name of the shell binary to be used to execute it.
If you want to use the `ksh` shell or the interpreted language `python`, you would replace the line:

```
#!/usr/bin/env bash
```

with :

```
#!/usr/bin/env ksh
```

or with :

```
#!/usr/bin/env python
```

This first line is called the `shebang`.
It is materialized by the characters `#!` followed by the path to the binary of the command interpreter to use.

Throughout the writing process, you should think about proofreading the script, using comments in particular:

* a general presentation, at the beginning, to indicate the purpose of the script, its author, its version, its use, etc.
* during the text to help understand the actions.

Comments can be placed on a separate line or at the end of a line containing a command.

Example:

```
# This program displays the date
date # This line is the line that displays the date!
```
Loading