20 bash interpreter

Starting from this lecture, we will talk about the command interpreter bash (" bash "), which is a descendant of the very first interpreter, sh or shell (" shell "). Sometimes speaking shell means bash , and speaking bash means shell . The difference between these names is sometimes quite conditional. We’ll talk about bash ( Bourne again Shell ).

All this time we have been working in the system through the bash command interpreter. Or in other words, we interacted with the system through the bash interpreter. This is the so-called interactive mode of working with the system. In addition, you can interact with the system using scripts . Script - is a text file in which any actions (programs, commands, other scripts) are executed sequentially. If you need to perform any actions every day (for example, backing up data and copying them to a backup server), it is convenient to record such actions as a script and then call only the name of the script (or automate the work using the cron daemon ).

How does bash understand that there is a script in front of it, and not a simple text file? If you remember, in Linux there is no concept of a file extension, and although for convenience some call script files in the form of * .sh , for the interpreter this does not matter. The main pointer is inside the file. When you run a program, execute a com *** u or script, bash begins to analyze the first characters of the file in the first line. If bash encounters ELF ( Executable and Linkable Format ) characters at the beginning, then this means that the file is a compiled file by the program (similar to exe-files in Windows ). If the first characters in the file are #! , then bash does the following. Takes the rest of the characters after the #! and to the end of the line (the character of the transfer to a new line), after a space, adds the name of the last command (that is, the name of the script) and executes the resulting com *** *** It may be difficult to decompose right away, so let's use an example (we'll need two consoles).

Type the following text in a text editor:

#! / bin / bash
sleep 100

Save the file with the name sleep.sh and do not forget to make it executable (set the x bit):

igor @ ubuntu: ~ / linux $ chmod u + x sleep.sh

Now run this file for execution:

igor @ ubuntu: ~ / linux $ ./sleep.sh

Now in the second console, execute com *** at:

igor @ ubuntu: ~ $ ps ax | grep bash
4861 pts / 0 Ss 0:00 bash
4955 pts / 1 Ss 0:00 bash
5011 pts / 0 S + 0:00 / bin / bash ./sleep.sh

Look at the process example with a PID of 5011 - / bin / bash ./sleep.sh . bash took the first line after #! , and this is / bin / bash and, with a space, added the name of the last command - ./sleep.sh and launched the resulting construction / bin / bash ./sleep.sh as a separate process.

To make it clearer, change the contents of the sleep.sh file to the following:

#! / bin / ls -l

and run the script:

igor @ ubuntu: ~ / linux $ ./sleep.sh
-rwxr – r– 1 igor igor 13 2009-12-15 22:04 ./sleep.sh

I hope you understand why this is exactly the result of the execution of the resulting script.

In most cases, after #! the complete let is specified to the interpreter for which the script is written. For example, if the text contained in the script is written in the perl language, then the first line would look like #! / Usr / bin / perl . As we study bash , in our examples this line will be the same as in the first example: #! / Bin / bash . Depending on the distribution, you may have other interpreters installed (for example, sh, dash, csh , etc.). The sh interpreter is older, simpler and considered faster than bash . System configuration scripts can start with the line #! / Bin / sh and if the sh interpreter is not installed on the system, create a symbolic link in the / bin directory with the name sh , which refers to an existing interpreter (for example, the same bash ). This is done in order not to rewrite the first line #! / Bin / sh for all existing scripts in the system.

To determine some information about the interpreter executable file (and not only the interpreter), you can use the following three *** groups: type , file, and ldd . A com *** type will show where bash finds the executable file of a command, file shows the file type (script, ELF , etc.), ldd shows which libraries are needed for the ELF file to work.

igor @ ubuntu: ~ / linux $ type bash
bash is / bin / bash

igor @ ubuntu: ~ / linux $ file / bin / bash
/ bin / bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU / Linux 2.6.15, stripped

igor @ ubuntu: ~ / linux $ ldd / bin / bash
linux-gate.so.1 => (0 × 00375000)
libncurses.so.5 => /lib/libncurses.so.5 (0 × 00db1000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0 × 00ba8000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0 × 00210000)
/lib/ld-linux.so.2 (0 × 001f3000)

Here is an example with a symbolic link:

SLES: ~ # type sh
sh is / bin / sh

SLES: ~ # file / bin / sh
/ bin / sh: symbolic link to `bash '

Just the case of sh , this is bash .

Now let's talk about I / O streams.
Next to the lecture was a conversation about input / output streams. This question is not simple, the teacher spoke a lot, drew diagrams, did not have time to write everything down, therefore, so as not to waste time on restoring this topic, I suggest reading a very good description of the streams in this article (thanks to the author). Although it is enough to read the section “Streams and files” (this is exactly what we were told at the lecture), but I recommend reading the articles in full.

In the next lecture, we’ll continue familiarity with bash as a programming language and begin to look at its basic constructs.