So, you’re scratching your head and saying, “What is a shell, and why should I care?” Well, a shell is a program that acts as an intermediary between the user and the operating system kernel. A user types commands into the shell, which passes them into the kernel for processing. The output is then presented to the user via the computer terminal, which can also referred to as the screen. The most common shell on Linux systems is bash, but the Z shell (zsh) has been gaining popularity in recent years. (I’ll explain why in Chapter 22, Using the Z Shell.) You’ll find bash as the default shell on most Linux distros and certain Unix-like distros such as OpenIndiana, and zsh as the default on Kali Linux.

The newest versions of macOS also have zsh set as the default shell. Fortunately, much of what you’ll learn about bash also works on zsh. The main difference is that zsh has a few cool features that bash doesn’t have. (Again, I’ll explain all about that in Chapter 22.) PowerShell, which originally was only available for Microsoft Windows operating systems, has also been available for Linux and macOS since 2016. PowerShell is a whole different animal, but you might find it quite useful, as you should see when we get to Chapter 23, Using PowerShell on Linux.

The coolest thing about modern operating system shells is that they’re much more than just an interface tool. They’re also full-blown programming environments with many of the same programming constructs as more complex programming languages, such as Pascal, C, or Java. Systems administrators can make their jobs much easier by using shell scripts to automate complex, repetitive tasks.

When you log into a text-mode Linux or Unix server, you’ll be presented with a black screen and some text, which looks like this:

Figure 1.1: Plain bash on a text-mode Debian Linux machine

This is the unadorned, plain-jane shell. Machines with desktop environments installed will interface with the shell via a terminal emulator, which will look something like this:

Figure 1.2: A terminal emulator that interfaces with bash on an OpenIndiana machine

The name of the terminal emulator will differ from one desktop environment to the next, but all do the same job. The advantage of using a terminal emulator is that you’ll have the luxury of using scroll bars, customizing the display, and using copy-and-paste for the command-line.

In any case, you can see which shell you’re using by typing:

donnie@fedora:~$ echo $SHELL
/bin/bash
donnie@fedora:~$

In this case, you see that you’re using bash.

It doesn’t matter how much of an expert you think you are, there will still be times when you’ll need to look up some bit of information. With Linux, Unix, and Unix-like operating systems, there are several options for that.

Understanding Manual Pages

Manual pages, or man pages for short, have been built into Unix-like operating systems since almost forever. To use a man page, just enter man, followed by the name of the command, configuration file, or system component for which you seek information. For example, you could find out how to use the ls command like this:

man ls

Most of the time, the man command will open a man page in the less pager. (Some Unix implementations might use the more pager instead, but I haven’t found any recent ones that do.) Either way, you’ll be able to scroll through the man page or perform key word searches within the page to find the information that you seek.

The man pages are divided into sections that each correspond to a different category. On most Unix-like and Linux systems, there are eight main categories, more commonly referred to as sections, which are as follows:

Table 1.1: Describing the man page sections

You’ll see the subdirectories that contain these man page files in the /usr/share/man/ directory. You also might see some subdirectories with names like man0p, man5p, or man8x. These subdirectories contain certain special-purpose man pages, which will differ on different Linux distros.

A lot of times, you won’t need to think about these sections, because the man command will pull up the proper man page for you. Other times, you will need to pay attention to these sections, because many key words for which you’ll search can be found in multiple sections. For example, here on the Fedora workstation that I’m using to write this, there are two man pages for printf. There are two ways to find them. First, you can use the man -aw command, like this:

[donnie@fedora ~]$ man -aw printf
/usr/share/man/man1/printf.1.gz
/usr/share/man/man3/printf.3.gz
[donnie@fedora ~]$

You can also use the whatis command, like this:

[donnie@fedora ~]$ whatis printf
printf (1)           - format and print data
printf (3)           - formatted output conversion
[donnie@fedora ~]$

Note that whatis is a synonym for man -f. You’ll get the same results with either command, but my own preference is to use whatis.

So, we have a printf man page in Section 1, which means that we have a normal user command that’s called printf. We also see a printf man page in Section 3, which means that there’s a library function that’s called printf. If you enter man printf, you’ll see the man page from Section 1. You’ll see that in the first line of the man page, which will look like this:

PRINTF(1)           User Commands               PRINTF(1)

If you instead want to see the man page from Section 3, you’ll need to specify that in your command, like this:

man 3 printf

To broaden your search for all man pages that contain printf in either the title or the description of the man page, even if it’s embedded into another text string, use either apropos or man -k, like this:

[donnie@fedora ~]$ apropos printf
asprintf (3)         - print to allocated string
BIO_printf (3ossl)   - formatted output to a BIO
BIO_snprintf (3ossl) - formatted output to a BIO
BIO_vprintf (3ossl)  - formatted output to a BIO
BIO_vsnprintf (3ossl) - formatted output to a BIO
curl_mprintf (3)     - formatted output conversion
dprintf (3)          - formatted output conversion
tpm2_print (1)       - Prints TPM data structures
fprintf (3)          - formatted output conversion
fwprintf (3)         - formatted wide-character output conversion
printf (1)           - format and print data
printf (3)           - formatted output conversion
. . .
[donnie@fedora ~]$

Again, either command will give you the same output, but my own preference has always been to use apropos.

Most of the time, your Linux system does a good job of keeping the man page index updated. Once in a while though, you’ll need to do it manually, like this:

[donnie@fedora ~]$ sudo mandb
[sudo] password for donnie:
Purging old database entries in /usr/share/man...
Processing manual pages under /usr/share/man...
Purging old database entries in /usr/share/man/ca...
Processing manual pages under /usr/share/man/ca...
. . .
. . .
Processing manual pages under /usr/local/share/man...
0 man subdirectories contained newer manual pages.
0 manual pages were added.
0 stray cats were added.
0 old database entries were purged.
[donnie@fedora ~]$

Okay, that about does it for the man page system. Let’s talk about the info system.

Understanding Info Pages

The info page system is newer, and was invented by Richard M. Stallman as part of the GNU Project. The unique part about it is that each info page contains hyperlinks that can lead you to additional pages of information. For example, to obtain information about the info system, enter info info. This info page contains a menu, which looks something like this:

* Menu:
* Stand-alone Info::            What is Info?
* Invoking Info::               Options you can pass on the command line.
* Cursor Commands::             Commands which move the cursor within a node.
. . .
., . .
* Variables::                   How to change the default behavior of Info.
* Colors and Styles::           Customize the colors used by Info.
* Custom Key Bindings::         How to define your own key-to-command bindings.
* Index::                       Global index.

Each underlined item you see is a hyperlink to another page. With your cursor keys, move the cursor to the hyperlink that you want to see, and hit the Enter key. To see an info page for a specific command, such as ls, just do this:

info ls

If you need help with navigating through the info pages, just hit the H key to bring up a navigation menu.

And, that’s about it for the info pages. Let’s talk about on-line documentation.

Getting to Know the Linux Documentation Project

The Linux Documentation Project has been around since almost forever, and is an invaluable resource. The best part about it is the Guides section, where you’ll find free-of-charge, full-length books about Linux and bash that you can download in a variety of formats. They’re all quite old, with the newest one having been last updated in 2014. For the Bash Guide for Beginners book and the Advanced Bash-Scripting book that you’ll find there, that doesn’t matter. The concepts in those two books are eternal, and haven’t really changed over the years. To see these books, go to https://tldp.org/guides.html.

Using Your Favorite Search Engine

If all else fails, just use your favorite search engine to find what you need to know about either scripting in general, or scripting on a particular operating system. You’ll find plenty of help, such as blog posts, YouTube videos, and official documentation. There are plenty of Linux-specific websites that offer help on various things, and it’s quite simple to find them.

Next, let’s talk about text editors.

To create your shell scripts, you’ll need a text editor that’s designed for Linux and Unix systems. You have plenty of choices, and which one you choose will depend upon several criteria:

• Are you editing on a text-mode machine or on a desktop machine?
• What features do you need?
• What is your own personal preference?

Text-mode Editors

Text-mode text editors can be used on machines that don’t have a graphical user interface installed. The two most common text-mode text editors are nano and vim. The nano editor is installed by default on pretty much every Linux distro, and is quite easy to use. To use it, just type nano, followed by the name of the file that you want to either edit or create. At the bottom of the screen, you’ll see the list of available commands. To invoke a command, press the CTRL key, followed by the letter key that corresponds to the desired command.

The downside of using nano is that it doesn’t have the full range of features that you might want in a programmers’ text editor. You can see here that the implementation of nano on my Fedora workstation has color-coding for the syntax, but it doesn’t automatically format the code.

Figure 1.3: The nano text editor on my Fedora workstation

Note that on other Linux distros, nano might not even have color-coding.

My favorite text-mode editor is vim, which has features that would make almost any programmer happy. Not only does it have color-coded syntax highlighting, but it also automatically formats your code with proper indentations, as you see here:

Figure 1.4: The vim text editor on my Fedora workstation

In reality, indentation isn’t needed for bash scripting, because bash scripts work fine without it. However, the indentation does make code easier for humans to read, and having an editor that will apply proper indentation automatically is quite handy. Additionally, vim comes with a powerful search-and-replace feature, allows you to split the screen so that you can work on two files at once, and can be customized with a fairly wide selection of plug-ins. Even though it’s a text-mode editor, you can use the right-click menu from your mouse to copy and paste text if you’re remotely logged in to your server from a desktop machine or if you’re editing a local file on your desktop machine.

The older vi text editor is normally installed on most Linux distros by default, but vim often isn’t. On some distros, the vim command will work, even if vim isn’t actually installed. That’s because the vim command on them might be pointing to either vim-minimal or even to the old vi. At any rate, to install full-fledged vim on any Red Hat-type of distro, such as RHEL, Fedora, AlmaLinux, or Rocky Linux, just do:

sudo dnf install vim-enhanced

To install vim on Debian or Ubuntu, do:

sudo apt install vim

As much as I like vim, I do have to tell you that some users are a bit put off from using it, because they believe that it’s too hard to learn. That’s because the original version of vi was created back in the Stone Age of Computing, before computer keyboards had cursor keys, backspace keys, or delete keys. The old vi commands that you used to have to use instead of these keys have been carried over to the modern implementations of vim.

So, most vim tutorials that you’ll find will still try to teach you all of those old keyboard commands.

Figure 1.5: This photo of me was taken during the Stone Age of Computing, before computer keyboards had cursor keys, backspace keys, or delete keys.

However, on the current versions of vim that you’ll install on Linux and modern Unix-like distros such as FreeBSD and OpenIndiana, the cursor keys, backspace key, and delete key all work as they do on any other text editor. So, it’s no longer necessary to learn all of those keyboard commands that you would have had to learn years ago. I mean, you’ll still need to learn a few basic keyboard commands, but not as many as you had to before.

GUI Text Editors

If you’re using a desktop machine, you can still use either nano or vim if you desire. But, there’s also a wide range of GUI-type editors available if you’d rather use one of them. Some sort of no-frills text editor, such as gedit or leafpad, is probably already installed on your desktop system. Some slightly fancier programmer’s editors, such as geany, kwrite, and bluefish, are available in the normal repositories of most Linux distros and some Unix-like distros. Your best bet is to play around with different editors to see what you like. Here’s an example of kwrite with color-coded syntax highlighting enabled:

Figure 1.6: The Kwrite text editor.

That’s about it for our overview of text editors for Linux. Let’s move on and talk about compiled versus interpreted programming languages.

Compiled programming consists of writing program code in a text editor, and then using a compiler to convert the text file into an executable binary file. Once that’s done, users of the program won’t be able to easily view the source code of the program. With interpreted programming, the program runs directly from a text file, without having to compile it first.

Compiled programming languages, such as C, C++, or Fortran, are good for when you need maximum performance from your programs. However, they can be fairly hard to learn, especially when it comes to the lower-level functions such as working with files. Interpreted languages might not offer quite as high a level of performance, but they are generally quite flexible, and generally easier to learn. Interpreted languages in general also offer a higher degree of portability between different operating systems. Shell scripting falls into the category of interpreted languages.

Here are some reasons why you might consider using an interpreted language:

• When you are looking for a simple solution.
• When you need a solution that is portable. If you pay attention to portability concerns, you can write one script that will work on different Linux distros, as well as on Unix/Unix-like systems. That can come in handy if you’re working in a large corporation with a large network of mixed operating systems. (You might even find some larger corporations that are still running legacy Unix systems, such as AIX, HPUX, or SUNOS, alongside more modern implementations of Linux, BSD, or macOS.)

And, here are some reasons why you might consider using a compiled language:

• When the tasks require intensive use of system resources. This is especially true when speed is extremely important.
• When you are using math operations that require heavy number crunching.
• When you need complex applications.
• When your application has many sub-components with dependencies.
• When you want to create proprietary applications, and prevent users from viewing the application source code.

When you think about it, pretty much every example of productivity, server, gaming, or scientific software falls into one or more of these categories, which means that they really should be built with compiled languages for best performance.

Okay, let’s now talk about sudo.

Some of the things you’ll do in this course will require you to have administrative privileges. While it’s possible and convenient to just log into the root command prompt, that’s something that I like to discourage as much as possible. For best security, and to get used to what you’d be doing in an enterprise setting, your best bet is to use sudo.

Modern Linux distros allow you to add yourself to an administrators’ group as you install the operating system. (That’s the wheel group on Red Hat-type systems, and the sudo group on Debian/Ubuntu-type systems.) To run a command that requires administrative privileges, just do something like this:

sudo nftables list ruleset

You’ll then be asked to enter the password for your own user account, rather than the one for the root user account.

That’s about all we need to say about this topic, so let’s summarize and move on to the next chapter.

In this chapter, I’ve laid a bit of the groundwork for what’s to come in the following chapters. We looked at what an operating system shell is, and why we would use one. Then, we looked at the various ways to find help, did a high-level overview of Linux text editors, and wrapped up with a discussion of compiled versus interpreted programming and a brief mention of why we want to use sudo to run administrative commands.

In the next chapter, we’ll begin looking at the various things that an operating system shell does for us. I’ll see you there.

1. What is the most widely-used shell for Linux systems?
   1. zsh
   2. bash
   3. korn
   4. csh
2. What will happen if you create a Linux shell script on a Windows computer with a Windows text editor, such as Notepad or Wordpad?
   1. The script will run fine on a Linux machine.
   2. Your Windows machine will just shut down in protest of the fact that you’re using it to create Linux scripts.
   3. The script won’t run on a Linux machine, because Windows text editors insert an invisible carriage return character at the end of each line.
   4. Former Microsoft CEO Steve Ballmer will visit you and explain why Linux is a cancer.
3. 3. In which section would you find the man pages for administrative commands?
   1. 1
   2. 3
   3. 5
   4. 6
   5. 8
4. Which of the following statements is true?
   1. Interpreted programming languages are good for programs that perform heavy-duty math problems.
   2. Compiled programming languages are generally better than interpreted languages for any large, complex programs.
   3. Examples of interpreted programming languages include C, C++, and Fortran.
   4. There’s no difference in performance between interpreted and compiled programming languages.
5. True or False: To run administrative commands, it’s best to just log into the root user account.

• 22 Best Linux Text Editors for Coding: https://phoenixnap.com/kb/best-linux-text-editors-for-coding
• Ballmer: “Linux is a Cancer”: https://www.theregister.com/2001/06/02/ballmer_linux_is_a_cancer/
• Microsoft once called Linux a cancer, and that was a big mistake: https://www.zdnet.com/article/microsoft-once-called-linux-a-cancer-and-that-was-a-big-mistake/
• VIM tutorial for Beginners: https://linuxconfig.org/vim-tutorial
• Distrowatch.com: https://distrowatch.com/
• The Linux Documentation Project: https://tldp.org/
• LinuxQuestions.org: https://www.linuxquestions.org/
• Linux man pages: https://linux.die.net/man/

1. b
2. c
3. e
4. b
5. False. It’s better to use sudo from your own user account.

Read this book alongside other users, Linux experts, and the author himself.

Ask questions, provide solutions to other readers, chat with the author via Ask Me Anything sessions, and much more. Scan the QR code or visit the link to join the community.

https://packt.link/SecNet