The tools of the trade

Changing the X display

When you set up your XF86Config file, you may have specified more than one resolution. For example, on page 107 we selected the additional resolution 1024x768 pixels. When you start X, it automatically selects the first resolution, in this case 640x480. You can change to the previous resolution (the one to the left in the list) by pressing the Ctrl-Alt-Keypad - key, and to the following resolution (the one to the right in the list) with Ctrl-Alt-Keypad +. Keypad + and Keypad - refer to the + and - symbols on the numeric keypad at the right of the keyboard; you can't use the + and - symbols on the main keyboard for this purpose. The lists wrap around: in our example, if your current resolution is 640x480, and you press Ctrl-Alt-Keypad -, the display changes to 1024x768. It's a very good idea to keep the default resolution at 640x480 until you have debugged your XF86Config parameters: 640x480 almost always works, so if your display is messed up, you can just switch back to a known good display with a single keystroke.

Selecting pixel depth

You can configure most display boards to display a number of different pixel depths (a different number of bits per pixel, which translates to a different number of colours). When you start X, however, it defaults to 8 bits per pixel (256 colours), which is a very poor rendition. To start it with a different number, specify the number of planes. For example, to start with 32 bits per pixel (4,294,967,296 colours), enter:

$ Startx ---bpp 32

With older display boards, which had relatively limited display memory, there was a tradeoff between maximum resolution and maximum pixel depth. Modern display cards no longer have this limitation.

Getting a shell

As we saw at the beginning of the chapter, your main tools are the shell and the editor, and that's what we saw on the sample screens. But when you start X, they're not there: you need to start them.

In KDE, you have two ways to start a terminal window:

• You can select the icon showing a monitor with a shell in front of it, third from the left at the bottom of the example above. This starts the konsole terminal emulator.
• You can start an xterm by pressing Alt-F2.You see a window like the one in the centre left of Figure 7-1 , enter the text xterm (as shown) and press Run or the Enter key.

Obviously the first is the intended approach, and it's easier. Nevertheless, I recommend using xterm at least until you're sure you want to stick with kde: there are some subtle differences, and konsole is intended to work with kde only. If you do stick with KDE, you should change the configuration of the konsole button to start xterm instead; that's relatively straightforward.

In fvwm2, you start an xterm from the left mouse menu, as shown above.

Shell basics

The most basic thing you can do with the shell is to start a program. Consider program names to be commands: like you might ask somebody to "wash the dishes" or "mow the lawn," you can tell the shell to "remove those files":

$ rm filel file2 file3

This starts a program called rm (remove), and gives it a list of three file names to remove.

If you're removing a whole lot of files, this could take a while. Consider removing the entire directory hierarchy /usr/obj, which is created when building a new version of the system (see page 595). This directory hierarchy contains about 15,000 files and directories, and it'll take a while to remove it. You can do this with the following command:

# rm -rf /usr/obj &

In this example, we have a couple of options led in by a hyphen (-) and also the character & at the end of the line.

• The r option tells rm to recursively descend into subdirectories. If you didn't specify this, it would remove all files in the directory /usr/obj and then exit, complaining that it can't delete directories.
• The f (force) option tells rm to continue on error; otherwise if anything goes wrong, it will stop.
• The & character at the end of the line tells the shell (not rm) to continue after starting the program. It can run for some time, and there's no need to wait for it.

Options

In the previous example, we saw a couple of options. By convention, they come between the command name and other parameters, and they're identified because they start with a hyphen character (-). There's a lot of variation, though, is depending on the individual program.

• Sometimes, as in the previous example, options consist of a single letter and can often be joined together.
• Some programs, like tar and ps, don't insist on the hyphen lead-in. In "Тaking control" , we'll see the command:

  # ps waux
  

  This command could equally well be written:

  #  ps –waux
  

  You may also come across programs that refuse to accept the hyphen at all.
• Sometimes options can have values. For example, in Chapter 23 we'll see:

  #  tcpdump -i pppO host hub.freebsd.org
  

  Here, ppp0 is an argument to the i option. In some cases, it must be written with a space; in others, it must be written without a space; and in others again, it can be written either way. Pay attention to this detail when reading man pages.
• In other cases, they can be keywords, in which case they need to be written separately. The GNU project is particularly fond of this kind of option. For example, when building the system you may see compiler invocations like these:

  cc -O -pipe -Dinline=rpcgen_inline -Wall –Wno–format-y2K -Wno-uninitialized
  \-D_FBSDID=_RCSID -c /usr/src/usr.bin/rpcgen/rpc_main.c
  

  With the exception of the last parameter, all of these texts are options, as the hyphen suggests.
• Options are specific to particular commands, though often several commands attempt to use the same letters to mean the same sort of thing. Typical ones are v for verbose output, q for quiet output (i.e. less than normal).
• Sometimes you can run into problems when you supply a parameter that looks like an option. For example, how do you remove a file called -rf? There are a number of solutions for this problem. In this example, you could write:

  $ rm ./-rf
  

This is an alternative file naming convention.

Shell parameters

When you invoke a program with the shell, it first parses the input line before passing it to the program: it turns the line into a number of parameters (called arguments in the C programming language). Normally the parameters are separated by white space, either a space or a tab character. For example, consider the previous example:

$ rm file1 file2 file3

the program receives four arguments, numbered 0 to 3:

What happens if you want to pass a name with a space? For example, you might want to look for the text "Mail rejected" in a log file. UNIX has a standard program for looking for text, called grep. The syntax is:

grep expression files

Argument 1 is the expression; all additional arguments are the names of files to search. We could write:

$ grep Mail rejected /var/log/maillog

But that would try to look for the text Mail in the files rejected (probably causing an error message that the file did not exist) and /var/log/maillog (where just about every line contains the text Mail). That's not what we want. Instead, we do pretty much what I wrote above:

$ grep "Mail rejected" /var/log/maillog

In other words, if we put quote characters "" around a group of words, the shell will interpret them as a single parameter. The first parameter that is passed to grep is Mail rejected, not "Mail rejected".

This behaviour of the shell is a very good reason not to use file names with spaces in them. It's perfectly legitimate to embed spaces into UNIX files names, but it's a pain to use. If you want to create a file name that contains several words, for example All files updated since last week, consider changing the spaces to underscores: All_files_updated_since_last_week.

It's even more interesting to see what happens when you pass a globbing character to a program, for example:

$ cc -o foo *.c

This invocation compiles all C source files (*.c) and creates a program foo. If you do this with Microsoft, the C compiler gets four parameters, and it has to find the C source files itself. In UNIX, the shell expands the text *.c and replaces it with the names of the source files. If there are thirty source files in the directory, it will pass a total of 33 parameters to the compiler.

Fields that can contain spaces

The solution to the "Mail rejected" problem isn't ideal, but it works well enough as long as you don't have to handle fields with blanks in them too often. In many cases, though, particularly in configuration files, fields with blanks are relatively common. As a result, a number of system configuration files use a colon (:) as a delimiter. This looks very confusing at first, but it turns out not to be as bad as the alternatives. We'll see some examples in the PATH environment variable on page 130, in the password file on page 144, and in the login class file on page 571.