This chapter covers a lot of material from Linux I. If you do not remember Linux I, you should read it carefully. The authors explain that this book is about getting ready for a Linux Professional Institute Certification 1 (LPIC-1) version 5 exam. They point out that the exam is about versions of Linux that were available when it was written. In that regard, they suggest that you may want to install the versions they used when they wrote the text:
This is not a list of all Linux distributions, but it is the list suggested by your authors. As a correction, I found I could not download a copy of CentOS 7, so I pulled down CentOS 8 instead. On the Ubuntu side, I did find a download for Bionic Beaver, so I pulled that down as well.
By the way, the first pages of each download document describe downloading and installing VMware with a free license from the college. Note that you can only do this once a year, so it is IMPERATIVE that you grab a screen image of your license number during this process, or that you write it down and do not lose it. If you have already installed VMware for another course, you do not have to download it again, and you certainly don't have to do it twice for this assignment.
The text continues with some tips on easily reaching a command line.
In each of the cases above, you will probably be in the default shell for your Linux distro. If that is not the one you want, several others may be available:
The text mentions the fact that the default shell for a distro is often called by /bin/sh, which is linked to the actual shell executable. In the case of Bash, the link may point to /bin/bash. Try the commands on pages 5 and 6 to confirm what the default shell is for your system.
The next few pages discuss the pitfalls of using the echo command.
The text reminds us that there are internal (contained in the shell program) and external (contained in their own files) commands. This does not usually matter, but the difference is important when you are troubleshooting where a problem is: bad copy of the shell, or missing/bogus copy of a file.
Before we go any further, we should consider why we might want to use a command line interface instead of a graphical user interface. This video discusses some of the reasons, and it also presents a tutorial on things you might not remember from Linux I.
So, flexible (although cryptic) options, speed of command entry, and speed of execution of file activities.
The text revisits variables, mentioning several environment variables which affect how the workstation runs. Several are discussed in later chapters, which is good. Talking about them out of context is not very enlightening. For now, know that the set command will show you most environment variables and their current values. You may wish to see the value of the path variable, which can be different for each user. Review: what is the purpose of the path variable?
You should review the material in this first section of the chapter, reading more carefully anything that is not familiar. For a more personable discussion of commands that matter, play the video below.
The second section of the chapter discusses file editors, which means it discusses text editors. It talks a lot about the vi editor, which is typically used because it is always there, and because the user has nothing else.
Text editors can be line editors or screen editors, the difference being what you see and what you can edit at any given moment.
The main reason for mentioning this is to console us that vi
is a screen editor, and that it is more user friendly than its
ancestors. (The earlier ones must have been a real pain.) Other
editors exist, and you may want to consider any of them as
alternatives. See this short review
of several editors that can be added to most UNIX/Linux
vi is called vi because it is
meant to be more visually
oriented than older editors. As the text explains, it immediately
displays changes that you make. (Rather what we would hope for,
isn't it? Other editors did not display their changes to their
users. You may wish to gasp in horror.) The book then tells
us that vi has three modes, each of which is used for a
different purpose. These modes are called by other names in other documentation, which can lead to a
lack of understanding when looking for supplemental training
If that is not enough to make you run screaming into the night, congratulations. Read the text, and keep breathing deeply and slowly.
Some people are passionate about their chosen text editor, mainly because it has features that they use a lot. This video is about the vim editor, an improved version of vi. The presenter likes it very much, and that is really the point. If you use something because it does what you need it to do, you will probably like it, or you will find something you like better. And you will only do that if you have a reason to use a text editor.
Sometimes you don't need a
real editor. If you just want to see what's in a text file, you
can use the cat command. If you want to combine
the contents of one file with those of another, you could do this
with cat and the >>
redirection operator, as you should remember, but there is another
This syntax would read file1 into memory, append the contents of file2, then write the resulting file as file3, The fact that the contents of file2 are appended to those of file1 in memory is unexpected, but that's how it can work.
To see only the first or last ten lines of a file, try the head or tail commands. It is useful to know what you want to with a file in order to use the right tool.
Selection commands are commands that extract information from files.
Manipulation and transformation commands do something with or to data or files.
The text moves on to discuss regular expressions, which is a strange name for a method of searching for text in a file. Let's try to combine some ideas. Use the grep utility, listed above, to search for text in a file, sed to edit a file/stream, and sort to arrange data.
The following video demonstrates the head, tail, and more commands. I looked at a lot of them that were dreadful, so enjoy this one for its clarity and brevity.
Another idea in the chapter is about data streams. Streams
are communication channels between a program (or an OS) and its
hardware/software environment. They exist for multiple programming
languages and for the operating systems we are talking about. We
generally care about three streams:
C, UNIX, and Linux treat all these streams like files, just like they do with everything else. They send data that is meant for a stream into it the same way they send data to any other file. The operating system you are running defines what the streams connect to.
The text explains that we can redirect the output of a process to a file (including the three streams) by using greater than symbols. Most processes take their input from a default location, such as stdin, but we can tell a process to take input from a file using less than symbols.
That ought to be enough for right now.