Shell preparation

Objective

It's a bit odd to write "opening" in the last section. H owever, at the beginning of the first (numerical operation) is actually a small opening, where the premise of the entire series is that there is a need for a certain shell programming foundation, so in order for readers who do not have the shell programming basis to read the series, I'll rewrite the beginning at the end. The opening section focuses on what shells are, shell operating environments, shell basic syntax, and debugging techniques.

What is a shell

Let's first look at the location of the shell throughout the operating system from the following image, which depicts the entire operating system (such as Debian/Ubuntu/Slackware which describes the core of the Linux Kernel Shell like the GUI between the user and the operating system.

GUI provides a graphical user interface that is easy to learn to Shell a command-line interface that receives the user's keyboard input, analyzes and executes commands in input strings, and then returns the execution results to the user, which can be more complex to use, but can be more efficient and batch-based because of the small resources consumed and the ability to perform batches.

Shell as a user interface, it is actually an interpreter that interprets and analyzes user keyboard input, executes commands in input, and then returns results linux commonly used Bash linux), and we can view the current shell with the Shell

$ echo $Shell
/bin/bash
$ ls -l /bin/bash
-rwxr-xr-x 1 root root 702160 2008-05-13 02:33 /bin/bash

The interpreter can interpret not only simple commands, but also a file with a specific syntax structure called Script. It explains exactly how these commands and script files are interpreted, not in depth here, see another article I wrote in 2008: "The Moment a Program Executes on the Linux Command Line."

Since the program can interpret a file with a certain syntax structure, then we can follow a syntax to write it, what kind of syntax does it have, how does it run, how do we debug it? Let's take Bash as an example to discuss these aspects.

Build the operating environment

For later exercises, let's set up a basic operating environment: in a Linux operating system, there is a command line running Bash waiting for us to type commands, which can be Terminal under the graphical interface Ubuntu Terminal under Ubuntu) or Console for the Console (you can switch with CTRL+ALT+F1~6 that the current Shell is not Bash replace it with the following method: Terminator

$ chsh $USER -s /bin/bash
$ su $USER

Or simply type Bash:

$ bash
$ echo $Shell  # 确认一下
/bin/bash

If you don't have a Linux operating system installed, you can also consider using some of the Linux virtual lab services provided by Shell with a remote shell that you can practice by logging in via Telnet or Ssh clients. Telnet

With a basic operating environment, how do you run commands that the user types or script files that the user writes? ?

Let's say we've written a shell script test.sh

The first is to make sure that the command we execute has executable permissions, and then type the command directly to execute it:

$ chmod +x /path/to/test.sh
$ /path/to/test.sh

The second approach is to pass the script directly in as a parameter of the Bash interpreter:

$ bash /path/to/test.sh

Or

$ source /path/to/test.sh

Or

$ . /path/to/test.sh

Introduction to basic syntax

Let's start with Hello, World program.

Here's a look at the basic structure of a shell program, Hello, World example:

#!/bin/bash -v
# test.sh
echo "Hello, World"

Save the above code as test.sh run it in two different ways above, you can see the following effect.

Method one:

$ chmod +x test.sh
$ ./test.sh
 ./test.sh
 #!/bin/bash -v

 echo "Hello, World"
 Hello, World

Method two:

$ bash test.sh
Hello, World

$ source test.sh
Hello, World

$ . test.sh
Hello, World

We found a difference between the two operating results, why? Here we need to look test.sh of the test.sh file, which has only two lines, the second line Hello, World both of which do the job, but the first method prints more of the contents of the script file itself, why?

The reason is that on the first line of the file, when we run the script file directly, the line tells the operating system to interpret the script #! and the corresponding parameters after the Bash and by analyzing the first line, we find that the corresponding interpreter and parameter is /bin/bash -v which is just -v print the source code of the program;

For additional grammar details, see Shell Programming Learning Notes, appendix I later in the book.

Shell program design process

Shell language as an explanatory language, its programming process and compilation language is somewhat different, the basic process is as follows:

• Design the algorithm
• Use a shell to script the program to implement the algorithm
• Run the script directly

It can be seen that it does not have the "troublesome" compilation and linking process of the compiled language, but it is precisely because it is not convenient to debug when it goes wrong, because both syntax errors and logical errors occur at runtime. Let's take a brief look at the debugging method.

Introduction to debugging methods

You can refer directly to: Shell script debugging techniques or BASH debugging techniques.

Summary

Shell language as an explanatory language, you can use a large number of existing tools, including numerical calculations, symbol processing, file operations, network operations, etc., so the writing process may be more efficient, but because it is explanatory, the need to constantly call external programs from disk during execution and switch between processes, there may be disadvantages in operational efficiency, so we should choose to use Shell or other languages for programming according to the application.

Resources

• The moment a program executes on the Linux command line
• Linux Shell programming learning notes
• Shell script debugging techniques
• BASH's debugging method