CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)

Chapter 4. Basic Command Line Usage

This chapter covers the following topics:

What Is a Shell?

Global and User Settings

Using the Command Line

Controlling Command Execution

Environment Variables and Settings

Setting Options in Bash

This chapter covers the following objectives:

Work on the command line: 103.1

One of the things that shocks newbies to the Linux command line environment is that nearly everything they see is text—command output, errors, data of all kinds, logs, and even emails are just simple text files.

Having the ability to properly manipulate and process large volumes of text is one of the most important attributes of a system administrator; without it you are just continually surrounded by meaningless data.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 4-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 4-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Which of the following words best describes what the Bash shell does with what we type into it?

a. Extrapolates

b. Interprets

c. Expresses

d. Translates

2. Which of the following files are executed upon a user’s terminal login?

a. /etc/profile

b. ~/.profile

c. ~/.bashrc

d. None of the above

3. You want to navigate from wherever you currently are on the system to the directory named .h, which is a subdirectory of the test directory in the currently logged-on user’s home directory. Which of the following will do this?

a. cd /home/{user}/test/.h

b. cd ../home/$USER/test/.h

c. cd ~/test/.h

d. None of the above

4. While monitoring your backup success and failure, you notice that at times your sole backup scheme is failing. As it’s a simple command typed at the command line, what character(s) could you use to separate the main command from an alternate command to ensure that if the first command fails, the secondary or alternative command will run, but only then?

a. **

b. ||

c. &&

d. !=

5. What is the simplest method of viewing all the variables in your execution environment?

a. env

b. getent

c. for * in $; echo

d. show all

6. You want to remove an option in the Bash Shell, which of the following would accomplish that? (Choose two.)

a. shoptout

b. undel

c. set +o

d. optdel

e. unset

Foundation Topics

What Is a Shell?

A shell is a program designed to interpret the commands users type, parse for expansions and wildcards, and then produce instructions to the computer to accomplish those tasks.

Unless you change the defaults, the Linux shell is normally the bash shell. Of course, many other shells exist.

A partial list is shown in Table 4-2.

Table 4-2 Common Shells

Among other pieces of information, the user’s default shell is specified in the /etc/passwd entry for that user. If the shell specified does not exist, the user gets the bash shell by default.

Special shells can be specified, such as /bin/false (which returns a nonzero error code, effectively blocking access by a user attempting to log in) or /etc/nologin (which is used to block logins for accounts and echo a message that login is denied).

Note

The /etc/nologin file should not normally exist on systems, as it disables logins. If your system suddenly doesn’t allow logins after you study this chapter, you know what you did!

Global and User Settings

When users log in to the system, either from a remote shell session or via the console, their environment is made up of information from various ASCII text files that are sourced or read to make up the user’s environment. Different distributions handle these differently, but to actually understand what happens on most systems, we focus on the Red Hat and Debian methods, which are outlined next.

Sourcing Versus Executing

It is critical to your development as a systems administrator to know the difference between “executing” a script and “sourcing” it.

Executing a Script

When you execute a script, Bash causes a new level of shell to be entered, and then the contents of the script file to be executed one by one as if they were entered on the command line by you.

While you are executing the script, and are in that new lower level of shell, all the variables and settings that are set are active in that level of shell and possibly below if exported.

When you exit the lower level of shell, for example, when the script is finished executing, then all the variables and settings that were acted upon are wiped out as the shell is exited.

Example of executing a script

# ./script1

Sourcing a Script

Sourcing a script is slightly but importantly different from executing it. Whereas in an executed script you are opening a new lower shell and then the commands are executed, a sourced script executes the lines of the script into the environment of the current shell.

With the number of environment configuration files that a user must “source” while logging in to a system, without sourcing, there would be three to five nested instances of the shell by the time the user gets to a shell prompt and can interact with the system.

With sourcing, the user is put into the shell, and the contents of the “sourced” configuration files are loaded into the current shell, making up the user’s environment.

You can source a script either of two ways:

# source script1
# . script1

A Login Shell Session

A login shell is one that is executed when logging in to the system. In other words, a login shell is one where either the user approaches the physical system and logs normally as a user, or does so across the network, and gets the full benefit of the contents of the files that make up the user’s environment.

The /etc/profile is the global configuration file that affects all users’ environments if they use the bash shell. It’s sourced (read) every time a user performs a login shell. This file is a script and is sourced right before the user’s profile script is sourced.

The user’s ~/.bash_profile script, if it exists, is the next script sourced. This file contains variables, code, and settings that directly affect that user’s—and only that user’s—environment. This script calls, or sources, the next script, which is ~/.bashrc.

Note

The ~/.bash_profile script can also be referred to or named as the .bash_login or .profile script. If all three exist, the ~/.bash_profile is sourced alone; otherwise, if it doesn’t exist, the .bash_login is sourced. Finally, if the first two are nonexistent, the .profile script is sourced. This functionality is used almost entirely by Bourne shell users upgrading to a bash system as a way to keep their settings in the same .profile file.

The ~/.bashrc file is called by the ~/.bash_profile or one of the profile’s aliases and is used to set various shell settings and options, set the prompt, and define aliases and functions for command-line execution.

The last script sourced during a user’s login session is the .bash_logout file. This file is used to issue the clear command, so text from any previous command is not left on the user’s screen after he logs out.

Note

Be careful on the exam because a lot of test-takers do not pick the .bash_logout file as part of the user’s login session. It’s definitely one of the more missed elements in the shell section.

An example of the user’s login session might be the following:

1. The user logs in with a username and password.

2. The /etc/profile is sourced.

3. The user’s ~/.bash_profile is sourced.

4. The user’s ~/.bashrc is sourced from within the ~/.bash_profile.

5. The user conducts his or her business.

6. The user initiates a logout with the logout or exit command or by pressing Ctrl+D.

7. The user’s .bash_logout script is sourced.

A Non-Login Shell Session

Non-login shell sessions are typically the root user using the su command to temporarily become another user or a sysadmin using su to become the root user without loading the entire environment of the root or other user.

When a user executes a non-login session, the only file sourced is the target account’s ~/.bashrc file. (On Red Hat machines, the first action in the ~/.bashrc is to source the /etc/bashrc file if it exists.)

Upon exiting that account’s login, no logout files or scripts are sourced, nor are the source account’s scripts run again.

On a Red Hat machine of the 7.3/AS 2.1 vintage, if the target user’s .bashrc file is not present, the /etc/bashrc file does not automatically get sourced. This can easily be tested if you rename the target user’s .bashrc file, put a variable in the /etc/bashrc, log in as that user, and attempt to echo the variable. Doing this causes the variable to not be there.

Table 4-3 shows each file and when it’s sourced.

Table 4-3 Order of Precedence for Configuration Files

Using the Command Line

Perhaps one of the most common and important tasks a sysadmin can perform and learn is to be competent with the command line or in the shell. Most of Linux demands good shell skills, and many server implementations don’t even load or use the GUI (XFree86) tools, so neglecting the shell is almost criminal negligence.

Note

LPI exams focus heavily on the commands, their options, and how they work together. If you’re not familiar or competent with the command line, passing the exams (and being a good sysadmin, for that matter) is virtually impossible. Almost 20 questions of the exam center on the command line/shell and, of those, at least 3 to 4 will be fill-in-the-blanks, so this is a critical area.

There Are Commands and, Well, Commands

At its simplest, a command is just that, a command. Though what might appear to be an actual binary or script on disk sometimes is not.

The following list shows the various types of commands:

Actual commands—These are binaries installed via a package or compiled and installed manually.

Scripts—These are text files that contain a set of commands and are set to be executable via the permissions.

Built-in commands—These are what appear to be commands and are actually resident in memory because they are a part of the code of the Bash shell.

Aliases—These are little macros that reside in the user’s environment. A typical one might be to alias the ls –l command so that you can just type “ll” and get the same results.

Functions—A more complex feature than just aliases, functions can do repetitive and recursive actions, be formatted more clearly, and essentially are scripts contained in system memory.

Note

Aliases and functions are covered in a later chapter, so the limited understanding you have from the previous definition is enough for this section.

Structuring Commands

For the most part, commands take the following form:

command options arguments

An example of a simple command is

A more complex example would be a command with an option:

ls –l

A command can also just be suffixed with an argument:

ls /etc

Adding on an argument to the command makes it more functional:

ls –l /etc

While most commands follow the preceding conventions, the positions of some of the options are flexible. Often, if you type a long command string, having to arrow or hotkey back to a certain position is just too much work, so some options can be tacked onto the end, like so:

ls /etc/profiles -R

The rule I recommend is to not tack on to the end of the command any options that require an argument. Likewise, if the -f option specifies a file, you can’t unhook the -f filename pairing and expect it to work.

Breaking Long Command Lines

When constructing a long command string, it’s often useful to break it up onscreen to make it easier to understand or more visually pleasing. The backslash (\) character is used to turn the Enter key into a line feed, not a carriage return. The backslash is for causing special characters to be taken literally.

The following example is confusing because it breaks when it wraps onscreen:

rpm –ql package1.1.1.rpm | xargs file | grep –i LSB | nl | pr | tac

You could break it like the following and still produce the same results:

rpm –ql package-1.1.1.i386.rpm \
>| xargs file \
>| grep –i LSB \
>| nl \
>| pr \
>| tac

Command Completion

The nicest option for the command line by far is the capability to have a <TAB> complete either a portion of a directory or filename or the command if it’s in the path.

For example, when you’re trying to find out which commands in the /usr/bin directory start with the letters ls, you can use the following:

/usr/bin/ls <TAB>
lsattr lsb_release lsdev lsdiff lskat
lskatproc
lspgpot

It also works well when changing from one directory to the other. You just need to insert a recognizably unique portion of the next element and press the Tab key to have it complete the directory name:

cd /home/rb <TAB>
cd /home/rbrunson/Des <TAB>
cd /home/rbrunson/Desktop/Se <TAB>
cd /home/rbrunson/Desktop/Settings <Enter>

Using <TAB> immediately after the rb characters completes the /home/rbrunson directory. Adding a slash (/) to that and typing Des and then <TAB> completes the Desktop directory. Finally, adding /Se to the end and then <TAB> completes the full path for the target directory.

Note

Tab completion is not just for speed; it’s for accuracy as well. Many a systems administrator has not deleted an entire filesystem by using Tab completion with the rm command.

Special Characters in the Shell

Numerous characters have special meaning to the shell; a smattering of which are defined in Table 4-4.

Table 4-4 Common Special Characters

Controlling Command Execution

When commands are executed, an exit status is always returned but not always displayed. To display the exit status, you must use the echo command and the string $?.

Possible Exit Statuses

The following executes a command that’s guaranteed to work, showing all files in the current user’s home directory:

ls –a ~
.acrobat .adobe .bash_history .bashrc .dvipsrc

Next, the command is run again with a special character and a special variable to return the exit status:

ls –a ~ ; echo $?
.acrobat .adobe .bash_history .bashrc .dvipsrc
0

0 is the exit status of the command, as echoed back by the $? variable.

Now, a command that is fake or you know won’t work is run (my favorite is farg). You must suffix it like the previous code with the $? variable; the exit status is something like 1 or 127—anything but 0:

farg ; echo $?
-bash: farg: command not found
127

To sum this up, either a program executes with no errors (successfully) and returns an exit status of 0 or it has a failure and returns an exit status that is a nonzero value, usually 1 or 127.

Note

One of my training class attendees long ago summed up exit statuses like this: “I feel like the system’s using sign language with me. If the command executed all right, it’s making an ‘OK’ sign. If there is an error, it’s using a different digit to show me that something didn’t work.”

Environment Variables and Settings

The parent process of all processes on a Linux machine is the init process, with a process ID (PID) of 1. The init process executable is /sbin/init, and its environment is inherited by all child processes.

Hard-coded into init is a default set of paths that are the basis for all paths added by the environment files. This default or set of base paths is shown here:

/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin

Viewing the system’s environment variables in a pure state is difficult because viewing them requires the user to log in and execute the same scripts he is viewing.

To view your environment, use env to show environment variables but not shell settings or shell-oriented variables; you can use the set command or the shopt command to see those.

The Path

The path is a colon-separated list of directories that are searched for executables. It’s normally used to locate commands not in the current directory, although Linux does not run a command in the current directory unless that directory is in the path.

You can always refer to an executable in your current directory with one of two methods:

Absolute pathname—/home/ulogin/command

Relative pathname—; ./command

Note

So, if you see topics on the exam about how a user tried to execute a file in the current directory but couldn’t, you know that the directory isn’t in the path. The user should refer to the file with the full path from the root (/) or prefix the filename with ./ for the shortest method.

The path is usually set in the /etc/profile for all users or the ~/.bash_profile for an individual user. It’s easy to alter the current path and add a directory without disrupting the previous path definitions. The following example shows how:

1. Edit /etc/profile or .bash_profile.

2. Navigate to the bottom of the file with the keystroke G.

3. Open a new line for editing with the keystroke o.

4. Add the following line, replacing yournewpath with the path that’s correct for your system:

export PATH=$PATH:yournewpath

Getting $HOME

Some shortcuts and variables point to the user’s home directory, and several utilities can take the user there quickly.

The HOME variable is read from the user’s home directory entry in the /etc/passwd file. This variable’s value is the full path to the current user’s home directory:

cd $HOME – takes you to /home/username

Another method is using the cd command alone. This takes the user back home with the least number of keystrokes.

Finally, you can refer to the user’s home directory with the tilde (~) character, so typing cd ~ gets the user home as well.

Note

The exam tests your ability to understand how a user can get home and what certain characters do for you. One of the most missed and misunderstood areas is the use of the ~username combination. Here’s an example:

Your system has a user named tarfoo, and you logged in as the root user. There is a directory named /root/tarfoo on the system. Running the command cd ~tarfoo takes you to the tarfoo user’s home directory, whereas running the command cd ~/tarfoo takes you to the /root/tarfoo directory.

bash’s History Feature

The history command shows the stack of previously executed commands.

bash’s history function depends on a variable called HISTFILE, normally set to the current user’s .bash_history file (located in the user’s home directory). When echoed, it returns the full path and name of the user’s history file, like so:

echo $HISTFILE
/home/rbrunson/.bash_history

When a user logs in with either a login or interactive/non-login shell, the user’s .bash_history file is opened. Normally, the history stack is not written to the .bash_history file until the user logs out of that shell session. In the case of a user logging in and then executing a bash subshell to the login shell, the subshell reads the parent shell’s history file and writes to it upon exit. You can see this happen if you do the following steps:

1. Log in to a machine as a user.

2. Execute the following command:

echo "this is the main shell history"

3. Then start a new shell:

bash

4. In the new shell, execute the following:

history

5. Execute these commands:

echo "this is the subshell history"
history

6. Exit the subshell with the following command:

exit

7. View your history stack with the following:

history

8. View the last 10 lines of the existing .bash_history file with the following:

tail $HISTFILE

Important History Variables

Variables are used to control bash’s use of history files. The following are common history variables that are initialized when the shell is started:

HISTFILE—Defaults to ~/.bash_history and is set in the environment at login.

HISTCMD—The history or index number of the current command, so echo $HISTCMD shows the number for that command.

HISTCONTROL—If it’s set to ignorespace, lines that start with a space are not added to the history file. If it’s set to ignoredups, a line that duplicates the previous line is ignored regardless of the times it’s repeated.

HISTFILESIZE—The amount of lines used for the history stack when it’s written to the history file. If the resulting stack is larger than the size indicated, it is truncated from the front of the file to match the correct size. The default is 500.

Setting Options in bash

bash uses the built-in command set to turn on or off options for the shell. New in bash version 2.0 and higher is the shopt command, which encompasses the functionality of the set command. LPI exams focus on the set command:

set -o option (sets the option to on)
set +o option (sets the option to off

The set command uses a –o option specifier when setting options to on; conversely, it uses a +o specifier to turn options to off.

Important bash Options

Bash has a set of options you should know about for the exam and for use in real life. The most common options are shown in the following list:

emacs or vi—These set the keymap style for editing the command line.

history—This option is on by default. The value of the variable HISTFILE is read to determine the history file.

hashall—On by default, this option enables a hash table of requested commands and their locations for repeated use of the command.

monitor—This option causes job control to make background processes run in a separate group and notify the console when they are ended or completed.

noclobber—This option is off by default; when it’s on, it disallows the overwriting of an existing file by a redirect symbol (>). A syntax error occurs if this is attempted. The use of double redirects (to append the file) is recommended.

noexec—A dry run for script files when turned on. Interactive shells ignore it, but a script syntax-checks all commands without executing them.

notify—Reports terminated jobs to the console immediately, instead of waiting until the next execution of the jobs command.

verbose—This option echoes or prints to the screen any commands before they are executed. It’s useful for the visually impaired users and as a check of the executed string.

Expect to see questions about how to toggle options with the set and unset commands. Remember that setting an option is accomplished with the set –o option syntax, whereas unsetting or removing an option requires the set +o option syntax. Expect to see such options as noclobber,history, vi, and emacs.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 21, “Final Preparation,” and the practice exams on the DVD.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 4-5 lists a reference of these key topics and the page numbers on which each is found.

Table 4-5 Key Topics for Chapter 4

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

argument

export

history

option

shell

special characters

variables

Review Questions

The answers to these review questions are in Appendix A.

1. Which of the following shell does not support inline editing of the command line?

a. Bash

b. Ash

c. pdKsh

d. csh

2. Read the following phrase: _________ is the process of reading the contents of a configuration script and loading the results of the commands in the current shell environment.

Which of the following words correctly completes the above statement?

a. Substituting

b. Transliterating

c. Loading

d. Parsing

e. Sourcing

3. While attempting to execute a command utility with a long name, you cannot remember the last several characters. After typing what you are sure of, what character or characters can you typically type next to find out the rest of the command?

a. ESC

b. Ctrl-Enter

c. Tab Tab

d. \~

4. After executing a command, you don’t see an error message, but the behavior of the command and its output are different. What could you type on the command line immediately afterward to see whether there was an error?

a. echo $#

b. echo $?

c. echo $

d. echo $|

5. Which of the following when executed on the command line immediately returns you to your home directory? (Choose all that apply.)

a. cd $HOME

b. cd `

c. cd ~

d. cd

e. cd /home

6. Which command can be used to show only the last 10 lines of your History file?

a. tail –f /var/log/history

b. history | tail

c. cat +10 $HISTFILE

d. lasthist