Using the Shell

Debian GNU/Linux: Guide to Installation and Usage" by John Goerzen and Ossama Othman is part of the HackerNoon Books Series. You can jump to any chapter in this book here. Using the Shell

6. Using the Shell

As you have been reading this book, you’ve been interacting with the shell already. The shell is the program that reads your commands and then does what you ask it to. In this chapter, you explore the shell in greater detail, with a special eye towards customizing the shell to work as you want it to.

6.1 Environment Variables

Every process has an environment associated with it. An environment is a collection of environment variables. A variable is a changeable value with a fixed name. For example, the name EMAIL could refer to the value [email protected]. The value can vary; EMAIL could also refer to [email protected].

Because your shell is a process like any other, it has an environment. You can view your shell’s environment by entering the printenv command. Figure 6.1 has some sample output from printenv. On your system, the output will be different but similar.

![Figure 6.1: Sample printenv output

](https://cdn.hackernoon.com/images/vSShvCAio4bqP19bBfmp6FnYQFk1-be93y0u.jpeg)

Environment variables are one way to configure the system. For example, the EDITOR variable lets you select your preferred editor for posting news, writing e-mail, and so on.

Setting environment variables is simple. For practice, try customizing your shell’s prompt and your text file viewer with environment variables. First, let’s get a bit of background information.

man less

This command lets you view the online manual for the less command. In order to show you the text one screenful at a time, man invokes a pager that shows you a new page of text each time you press the space bar. By default, it uses the pager called more.

Go ahead and glance over the man page for less, which is an enhanced pager. Scroll to a new page by pressing space; press q to quit. more will also quit automatically when you reach the end of the man page.

export PAGER=less

After reading about the advantages of less, you might want to use it to read man pages. To do this, you set the environment variable PAGER.

The command to set an environment variable within bash always has this format:

export NAME=value

export means to move the variable from the shell into the environment. This means that programs other than the shell (for instance, a file viewer) will be able to access it.

echo $PAGER

This is the easiest way to see the value of a variable. $PAGER tells the shell to insert the value of the PAGER variable before invoking the command. echo echoes back its argument: in this case, it echoes the current PAGER value, less.

man more

Displays the more manual. This time, man should have invoked the less pager.

less has lots of features that more lacks. For example, you can scroll backward with the b key. You can also move up and down (even sideways) with the arrow keys. less won’t exit when it reaches the end of the man page; it will wait for you to press q.

You can try out some less-specific commands, like b, to verify that they don’t work with more and that you are indeed using more.

unset PAGER

If you don’t want to specify a pager anymore, you can unset the variable. man will then use more by default, just as it did before you set the variable.

echo $PAGER

Because PAGER has been unset, echo won’t print anything.

PS1=hello:

Just for fun, change your shell prompt. $ should now change; see Figure 6.2 for details.

export is not necessary, because you’re changing the shell’s own behavior. There’s no reason to export the variable into the environment for other programs to see. Technically, PS1 is a shell variable rather than an environment variable.

If you wanted to, you could export the shell variable, transforming it into an environment variable. If you do this, programs you run from the shell can see it.

6.2 Where Commands Reside: The PATH Variable

When you type a command into the shell, it has to find the program on your hard disk before executing it. If the shell had to look all over the disk, it would be very slow; instead, it looks in a list of directories contained in the PATH environment variable. This list of directories makes up the shell’s search path; when you enter a command, it goes through each one in turn looking for the program you asked to run.

You may need to change the PATH variable if you install programs yourself in a non-standard location. The value of PATH is a colon-separated list of directories. The default value on Debian systems is as follows:

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

This value is defined in the file /etc/profile and applies to all users. You can easily change the value, just as you can change any environment variable. If you type the command ls, the shell will first look in /usr/local/bin; ls isn’t there, so it will try /usr/bin; when that fails, it will check /bin. There it will discover /bin/ls, stop its search, and execute the program /bin/ls. If /usr/bin/X11/ls existed (it doesn’t, but pretend), it would be ignored.

You can see which ls the shell is going to use with the type command. type ls will give you the answer /bin/ls. Try it yourself.

Try asking where type itself resides:

$ type type
type is a shell builtin

type isn’t actually a program; it’s a function provided by the shell. However, you use it just like an external program.

There are a number of commands like this; type man builtins to read the man page describing them. In general, you don’t need to know whether a command is a builtin or a real program; however, builtins will not show up in the output of ps or top because they aren’t separate processes. They’re just part of the shell.

6.3 Configuration Files

Many applications on Linux systems allow you to alter how they behave at certain times by altering files containing configuration information. These configuration files may contain application start-up information, run-time settings and application shutdown settings. In general, a configuration filename is based on the name of the application for which it contains settings. Such a naming convention allows you to more readily determine which configuration file contains settings for a given application.

6.3.1 System-Wide Versus User-Specific Configuration

It’s important to remember that there are two different kinds of configurations on a Debian system. System-wide configuration affects all users. System-wide settings are made in the /etc directory, so you generally must be root in order to change system-wide settings. You might configure the way the system connects to the Internet, for example, or have web browsers on the system always start on the company home page. Since you want these settings to apply to all users, you make the changes in /etc. Sample configuration files in /etc include /etc/X11/XF86Config, /etc/lynx.cfg, and /etc/ppp/options. In fact, nearly all the files in /etc are configuration files.

User configuration affects only a single user. Dotfiles are used for user configuration. For example, the file ~/.newsrc stores a list of which USENET (discussion group) articles you have read and which groups you subscribe to. This allows news readers such as trn or GNUS to display unread articles in the groups you’re interested in. This information will be different for every user on the system, so each user has his own .newsrc file in his home directory.

6.4 Aliases

If you use the same command often, you might get tired of typing it. bash lets you write shorter aliases for your commands.

Say you always use the -almost-all and -color=auto options to ls. You quickly get tired of typing ls -almost-all -color=auto. So you make an alias:

alias myls=’ls -almost-all -color=auto’

Now you can type myls instead of the full command. To see what myls really is, run the command type myls. To see a list of aliases you’ve defined, simply type alias on a line by itself.

6.5 Controlling Input and Output

Throughout your experiences with Linux, you will most likely find that manipulating application input and output can be a very powerful thing to do. This section describes some of the things that controlling input and output can do for you.

6.5.1 stdin, stdout, Pipelines, and Redirection Every process has at least three connections to the outside world. The standard input is one source of the process’s data; the standard output is one place the process sends data; and the standard error is a place the process can send error messages. (These are often abbreviated stdin, stdout, and stderr.)

The words “source” and “place” are intentionally vague. These standard input and output locations can be changed by the user; they could be the screen, the keyboard, a file, even a network connection. You can specify which locations to use.

When you run a program from the shell, usually standard input comes from your keyboard, and standard output and error both go to your screen. However, you can ask the shell to change these defaults.

For example, the echo command sends it output to standard output, normally the screen. But you can send it to a file instead with the output redirection operator, >. For example, to put the word “Hello” in the file myfile, use this command:

echo Hello > myfile

Use cat or your text file pager (more or less) to view myfile’s contents; see Figure 6.3.

You can change the standard input of a command with the input redirection operator, <. For example, cat < myfile will display the contents of myfile. This is not useful in practice; for convenience, the cat command accepts a filename argument. So you can simply say cat myfile, and the effect will be the same. redirection operators

Under the hood, cat < myfile means that the shell opens myfile and then feeds its contents to the standard input of cat. cat myfile, without the redirection operator, means that the cat command receives one argument (myfile) opens the file itself, and then displays the file.

There’s a reason for the double functionality, however. For example, you can connect the standard output of one command to the standard input of another. This is called a pipeline, and it uses the pipe operator[1], |.

[1] Depending on your keyboard, this may either appear as a vertical bar or a broken vertical bar, but it can almost always be found above the backslash ().

Perhaps you want to see the GNU General Public License in reverse. To do this, you use the tac command (it’s cat, only backward). Try it out:

tac /usr/doc/copyright/GPL

Unfortunately, it goes by too quickly to read. So you only get to see a couple of paragraphs. The solution is a pipeline:

tac /usr/doc/copyright/GPL | less

This takes the standard output of tac, which is the GPL in reverse, and sends it to the standard input of less.

You can chain as many commands together as you like. Say you have an inexplicable desire to replace every G with Q. For this you use the command tr G Q, like this:

tac /usr/doc/copyright/GPL | tr G Q | less

You could get the same effect using temporary files and redirection, for example:

tac /usr/doc/copyright/GPL > tmpfile tr G Q < tmpfile > tmpfile2 less < tmpfile2 rm tmpfile tmpfile2

Clearly a pipeline is more convenient.

6.6 Filename Expansion

Often you want a command to work with a group of files. Wildcards are used to create a filename expansion pattern: a series of characters and wildcards that expands to a list of filenames. For example, the pattern /etc/* expands to a list of all[2] the files in /etc.

[2] Actually, files beginning with . are not included in the expansion of *.

• is a wildcard that can stand for any series of characters, so the pattern /etc/* will expand to a list of all the filenames beginning with /etc/.

  
  

This filename list is most useful as a set of arguments for a command. For example, the /etc directory contains a series of subdirectories called rc0.d, rc1.d, etc. Normally to view the contents of these, you would type the following:

ls /etc/rc0.d /etc/rc1.d /etc/rc2.d /etc/rc3.d ls /etc/rc4.d /etc/rc5.d /etc/rc6.d /etc/rcS.d

This is tedious. Instead, you can use the ? wildcard as shown here:

ls /etc/rc?.d

/etc/rc?.d expands to a list of filenames that begin with rc, followed by any single character, followed by .d.

Available wildcards include the following:

• Matches any group of 0 or more characters.

  
  

? Matches exactly one character.

[...] If you enclose some characters in brackets, the result is a wildcard that matches those characters. For example, [abc] matches either a, or b, or c. If you add a ^ after the first bracket, the sense is reversed; so [^abc] matches any character that is not a, b, or c. You can include a range, such as [a-j], which matches anything between a and j. The match is case sensitive, so to allow any letter, you must use [a-zA-Z].

Expansion patterns are simple once you see some concrete examples:

*.txt This will give you a list of all filenames that end in .txt, since the * matches anything at all.

*.[hc] This gives a list of filenames that end in either .h or .c.

a?? This gives you all three-letter filenames that begin with a.

[^a]?? This gives you all three-letter filenames that do not begin with a.

a* This gives you every filename that starts with a, regardless of how many letters it has.

About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books.

This book is part of the public domain. John Goerzen and Ossama Othman (2004). Debian GNU/Linux : Guide to Installation and Usage. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/6527/pg6527-images.html

This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org, located at https://www.gutenberg.org/policy/license.html.