Debian GNU/Linux: Guide to Installation and Usage, John Goerzen and Ossama Othman [read e book TXT] 📗

information you want people to see in a file called .plan. To do this you’ll use a text editor; see section 8.2 on page [*]. Then finger yourself to see your plan. Others can finger you to see your plan and to check whether you’ve received new mail or read your mail.

 

Note that this finger information is available to the entire Internet by default. If you don’t want this, read about configuring inetd and the file etcservices. Eventually the installation manual will describe this configuration, but for now you might try the man pages or just put nonsense in for your finger information.

 

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.

 

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 joe@nowhere.com. The value can vary; EMAIL could also refer to jane@somewhere.com.

 

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: Sample printenv output begin{figure}parparbegin{list}{}{ setlength{rightmargin}{leftmargin}

ra… …ables}index{shells!environments}

par_=usrbin/printenvend{list}end{figure}

 

Figure 6.1 on page [*] has some sample output from printenv. On your system, the output will be different but similar.

 

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:

 

Figure 6.2: Changing the prompt begin{figure}parparbegin{list}{}{ setlength{rightmargin}{leftmargin}

ra… …o~My~prompt~is~$PS1} par My~prompt~is~hello: par hello:end{list}end{figure}

 

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.

 

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: usrlocal/bin:usrbin:/bin:usrbin/X11:usrgames This value is defined in the file etcprofile 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 usrlocal/bin; ls isn’t there, so it will try usrbin; when that fails, it will check bin. There it will discover bin/ls, stop its search, and execute the program binls. If usrbin/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 binls. 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.

 

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 startup 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.

 

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 etcX11/XF86Config, etclynx.cfg, and etcppp/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.

 

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.

 

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.

 

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 on page [*].

 

Figure 6.3: Redirecting output begin{figure}parparbegin{list}{}{ setlength{rightmargin}{leftmargin}

ra… …llo~>~myfile} par$~textbf{cat~myfile} par Hello par$end{list}end{figure}

 

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 operator6.1, |.

 

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 usrdoc/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 usrdoc/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