Hour 2 An Unsung Resource: Unix Documentation

The last hour discussed various nuances of Unix installation on smaller computers. This hour starts you toward becoming a Unix system administration expert. Our goal for this hour is to explore the valuable online documentation that’s included with your Unix system. Along the way, we’ll read through some shell scripts and Perl scripts, and fix a system bug, too.

In this hour you will learn the philosophy of digging, including

• How to use apropos to search through documentation

• How to find just the right command you need

• How to use the strings command to dig around binary files

The Philosophy of Digging

As promised in the Introduction, the fundamental approach to system administration I’d like to teach you in this book is what I call The Philosophy of Digging. It refers to the value of learning how to find things in the Unix world, and how it’s ultimately more helpful than knowing commands themselves.

How can that be? Well, imagine this common scenario: You’ve been working with Mandrake Linux on your home computer to learn the Unix operating system, and your boss asks you to start maintaining a Red Hat Linux box. So far, so good. Three weeks later, a new Chief Technology Officer is hired and she announces, ″All servers will be replaced with Sun Solaris systems forthwith!″ Now you’re going to move into a completely new Unix environment. Worse, your son hacks your home computer and replaces your trusty Mandrake Linux with FreeBSD, convinced that it’s superior.

In a situation like this, having memorized all the Linux commands and flags is going to prove of limited value at best. But if you’ve learned a philosophy of digging, a strategy of exploring the system starting with the man pages themselves, you’ll be able to get up to speed on the new Unix flavors in remarkably little time.

So let’s see how that works in this chapter, as we begin to explore the online Unix documentation suite.

apropos: The Administrator’s Secret Weapon

One of the classic dilemmas that a system administrator faces in the world of Unix, whether highly experienced or a neophyte, is to remember the name of the command that does just what you want. Then, once you recall the command, you must remember the exact sequence of flags and arguments that’ll bend the system to your will and accomplish your task.

The secret weapon that smart sysadmins use is the apropros command (also known as man -k, because they’re the same thing). apropos works with a database of one-line command summaries for the entire Unix system.

Task 2.1: apropos and the whatis Database

To search for commands related to a specific topic, type apropos followed by the word you seek. It’ll quickly search a prebuilt database of command summaries (more than 15,000 of ‘em) and show you all the matches.

1. Let’s get started by looking for commands related to online documentation:

    $ apropos help
    help: nothing appropriate

Hmmm…This is a little puzzling, because there are a number of Unix commands that contain the word ″help″ in their description, so there should be a number of matches. If you do get a list of possible matches, congratulations, your vendor set things up properly and you can skip the next few paragraphs, but don’t. Read it instead; it’s an informative journey into the recesses of Unix.

Perhaps something’s wrong with this system configuration. Let’s dig around a bit, shall we?

2. A quick check of the apropos man page gives us a hint:

    $ man apropos
    apropos(1)                                            apropos(1)

    NAME
           apropos - search the whatis database for strings

    SYNOPSIS
           apropos keyword …

    DESCRIPTION
           apropos  searches a set of database files containing short
    descriptions of system commands
           for keywords and displays the result on the standard output.

    SEE ALSO
           whatis(1), man(1).

    (END)

The critical part of this man page entry is the SEE ALSO section. Here it’s pointing us to two other commands for more information: whatis and man. Because we already know the basics of the man command, let’s have a peek at the whatis entry to see what it contains.

    $ man whatis
    whatis(1)
                                                        whatis(1)

    NAME
       whatis - search the whatis database for complete words.

    SYNOPSIS
           whatis keyword …

    DESCRIPTION
           whatis searches a set of database files containing short
    descriptions of system commands
           for keywords and displays the result on the standard output.
      Only complete word matches
           are displayed.

           The whatis database is created using the command /usr/sbin/
    makewhatis.

    SEE ALSO
           apropos(1), man(1).

    (END)

There’s the clue we’re seeking: ″The whatis database is created using the command /usr/sbin/makewhatis.″

Rather than just run that command, however, let’s dig into it and see if we can figure out the name of the database file itself.

3. To see the contents (instructions) within a system program, the first step is to use the file command, so we know what to expect:

    $ file /usr/sbin/makewhatis
    /usr/sbin/makewhatis: Bourne shell script text executable

Great! It’s a shell script, so we can just step through it and see what’s inside. Much easier to deal with than a compiled binary (but we’ll look at digging through those in a little while).

    $ head /usr/sbin/makewhatis
    #!/bin/sh
    # makewhatis aeb 010319 (from man-1.5i1)

    program=‘basename $0’

    DEFMANPATH=/usr/share/man:/usr/man
    DEFCATPATH=/var/cache/man:/usr/share/man/preformat:/usr/man/preformat:
    /usr/share/man:/usr/man

    # AWK=/usr/bin/gawk
    AWK=/bin/gawk

Following these few definitions (which might be prefaced by lots and lots of comments or almost none, depending on your flavor of Unix) are many lines of shell script code, and about 75 lines into the script is the following snippet:

        -u) if [ -e /var/cache/man/whatis ]; then
              findarg=″-newer /var/cache/man/whatis″
              update=1

            fi
            continue;;

Here we can see that this is part of a section of code that parses starting arguments. The -u flag indicates that makewhatis should update the database with new commands (it’s detailed in the script), so it’s unsurprising to find the script testing for the existence of the whatis database.

And that’s what we’ve been seeking: The name of the database that is used by makewhatis—and therefore by whatis and apropos—is /var/cache/man/whatis.

4. By contrast, Darwin (which, you’ll recall, is the Unix underneath Mac OS X) is from the BSD Unix family, so it’s a bit different. First off, the man page for apropos is more informative, with the following information included:

    FILES
        whatis.db  name of the apropos database

    SEE ALSO
         man(1),  whatis(1),  whereis(1),  makewhatis(8)

Not only does this establish the direct connection between apropos and the whatis command, but it also points to the tool needed to make the database, and even tells us that apropos uses the whatis.db file!

A quick man makewhatis reveals

    SYNOPSIS
         /usr/libexec/makewhatis [manpath]

Now we have the location of the command in Darwin (note how different the file structure is!).

Interestingly, file reveals a surprising change:

    $ file /usr/libexec/makewhatis
    /usr/libexec/makewhatis: perl commands text

It’s a Perl script, rather than a Bourne shell script. For the last step, let’s look in the Perl script to find the name and location of the database file.

This proves to be tricky. The closest you can find in the script directly is the following (quite a ways down in the code!):

    sub variables {
        $verbose = 0;               # Verbose
        $indent = 24;               # indent for description
        $outfile = 0;               # Don′t write to ./whatis
        $whatis_name = ″whatis.db″; # Default name for DB
        $append = 0;                # Don′t delete old entries

       # if no argument for directories given
       @defaultmanpath = ( ′/usr/share/man’ );

From this, you can imply that the database will end up being saved as /usr/share/man/whatis.db.

5. A smarter way to ascertain the output filename is to simply log in as root (or use su to change to root), then rebuild the database with the -v flag specified.

    $ makewhatis -v
    Open /usr/share/man/whatis.db.tmp
    open manpath directory ‘ ‘/usr/share/man′ ′
    lots and lots of output as it lists each man page it finds and parses
    sort -u > /usr/share/man/whatis.db.tmp
    Rename /usr/share/man/whatis.db.tmp to /usr/share/man/whatis.db
    2068 entries in /usr/share/man/whatis.db

Not only did this answer the question of ″where’s the database for apropos?″ but it also built it!

Contrast the preceding output from Darwin with the following output from Red Hat Linux:

    # /usr/sbin/makewhatis -v
    about to enter /usr/share/man
    adding ./uuidgen.1.gz
    lots and lots and lots of output omitted
    adding ./vacuum.l.gz
    about to enter /usr/man
    /usr/sbin/makewhatis: cd: /usr/man: No such file or directory

Ahhh…very interesting. The command failed on a stock RHL7.2¹ system. Having to fix bugs and tweak the system just to get things to work in the first place is not an uncommon occurrence in the world of Unix system administration.

¹RHL7.2 is shorthand for Red Hat Linux release 7.2. This type of shorthand is very common in the Unix world, and you should try to get used to seemingly cryptic acronyms. Very much part of the Unix culture!

So let’s fix this bug, shall we?

6. First off, it’s rather surprising that there isn’t a /usr/man directory, because that’s part of standard (System V) Unix. Let’s have a peek to ensure that we’re reading this properly:

Lots of stuff, but no man directory.

We have two ways of addressing this problem. The easy solution is to create /usr/man as a directory and leave it empty. The more sophisticated solution, however, is to dig through the makewhatis shell script to see why it looks in /usr/man in the first place, and teach it to ignore that directory.

The good news is that the more sophisticated solution is actually pretty easy. If you flip back a page or two, you’ll see that at the very top of the script there’s a variable DEFMANPATH that’s defined as

    DEFMANPATH=/usr/share/man:/usr/man

My guess is that if we simply rewrite this as /usr/share/man and nothing else, we’ll be golden and it’ll work.

The change is simple, and because I like to leave a trail of comments for later reference, I’m not going to simply delete the :/usr/man suffix on the DEFMANPATH line, but instead change it as follows:

    DEFMANPATH=/usr/share/man       # also used to include ″:/usr/man″

Now, with this modification, I run the mkwhatis command again on the Red Hat Linux system and it works flawlessly! Hurray!

7. In contrast to both of these solutions, the Solaris system has a very different man page for apropos, but the great news is that in the man page it states that ″The apropos utility displays the man page name, section number, and a short description for each man page whose NAME line contains a keyword. This information is contained in the /usr/share/man/windex database created by catman(1M). If catman(1M) was not run, or was run with the -n option, apropos fails.″

A pointer to the command needed to fix things is always appreciated, and this even details the exact filename in question, too! Let’s pop over to catman and see what it says on that man page:

    $ man catman
    NAME
         catman - create the formatted files for the reference manual

    SYNOPSIS
         /usr/bin/catman [ -c ]  [ -n ]  [ -p ]  [ -t ]  [  -w  ]   [
         -M directory ]  [ -T macro-package ]  [ sections ]

    DESCRIPTION
         The catman utility creates the preformatted versions of the
         online manual from the nroff(1) or sgml(5) input files.
         This feature allows easy distribution of the preformatted
         manual pages among a group of associated machines (for exam-
         ple, with rdist(1)), since it makes the directories of pre-
         formatted manual pages self-contained and independent of the
         unformatted entries.

         catman also creates the windex database file in the direc-
         tories specified by the MANPATH or the -M option. The win-
         dex database file is a three column list consisting of a
         keyword, the reference page that the keyword points to, and
         a line of text that describes the purpose of the utility or
         interface documented on the reference page. Each keyword is
         taken from the comma separated list of words on the NAME
         line before the ′-′ (dash). The reference page that the key-
         word points to is the first word on the NAME line. The text
         after the - on the NAME line is the descriptive text in the
         third column. The NAME line must be immediately preceded by
         the page heading line created by the .TH macro (see NOTES
         for required format).

         Each manual page is examined and those whose preformatted
         versions are missing or out of date are recreated. If any
         changes are made, catman recreates the windex database.

Seems reasonable enough. To build the database, run the catman command with the -w flag. If there are no problems, there’s no output and everything should be installed and ready to run. Let’s have a quick test:

    # apropos solaris | wc -l
          54

Great!

8. Now on any of our systems we can run the apropos command and find out what commands are related to the topic help:

    $ apropos help
    B::Stackobj         (3pm)  - Helper module for CC backend
    consolehelper       (8)  - A wrapper that helps console users run
    system programs
    forum               (1)  - Interactive Help for MRTG users
    help [builtins]     (1)  - bash built-in commands, see bash(1)
    help [faq]          (1)  - How to get help if you have problems with MRTG
    LDP                 (7)  - Intro to the Linux Documentation Project, with
    help, guides and documents
    mibhelp             (1)  - A Table of some interesting OIDs
    Pod::ParseUtils     (3pm)  - helpers for POD parsing and conversion
    QCharRef [qcharref] (3qt)  - Helper class for
    QToolTip [qtooltip] (3qt)  - Tool tips (sometimes called balloon help)
    for any widget or rectangular part of a widget
    QXmlNamespaceSupport [qxmlnamespacesupport] (3qt)  - Helper class for XML
    readers which want to include namespace support
    smbmnt              (8)  - helper utility for mounting SMB filesystems
    userhelper          (8)  - A helper interface to pam

This is from Linux, and you can see that there are a number of commands. Notice that they all have the letters h-e-l-p somewhere in their command or description text, but they don’t all necessary relate to user-level help commands.

Oftentimes you only want to see the interactive commands rather than the system maintenance commands, and so on. One simple way to do that is to use egrep:

    $ apropos help | egrep ′(1|8)′
    consolehelper       (8)  - A wrapper that helps console users run
    system programs
    forum               (1)  - Interactive Help for MRTG users
    help [builtins]     (1)  - bash built-in commands, see bash(1)
    help [faq]          (1)  - How to get help if you have problems with MRTG
    mibhelp             (1)  - A Table of some interesting OIDs
    smbmnt              (8)  - helper utility for mounting SMB filesystems
    userhelper          (8)  - A helper interface to pam

A further nuance might be to feed this to sort such that it shows you all the section 1 commands, then the section 8 commands, but I’ll leave that as an exercise for you!

What started out as a simple task of learning how to use the apropos command rapidly spun out of control, and ended up roaming far and wide as we found and fixed some system configuration problems. This is very typical of your day-to-day experience as a system administrator, as you’ll find out as you spend more time learning Unix from the admin perspective.

Exploring the whatis Database

Now that we know how to build the whatis database, let’s spend a few minutes digging inside of it to see what we can learn. Just a short additional sidetrack, I promise!

Task 2.2: What’s Inside the whatis Database

Being curious folk, we can’t leave the database alone without a little exploration, so let’s have a peek.

1. The database itself is a regular text file, so we can use head to see what’s inside:

    # cd /var/cache/man
    # file whatis
    whatis: ASCII English text
    # head whatis
    411toppm             (1)  - convert Sony Mavica .411 image to PPM
    a2p                  (1)  - Awk to Perl translator
    a2ps                 (1)  - format files for printing on a PostScript printer
    ab                   (8)  - Apache HTTP server benchmarking tool
    abbrev [Text::Abbrev] (3pm)   - create an abbreviation table from a list
    abort                (3)  - cause abnormal program termination
    ABORT [abort]        (l)  - Aborts the current transaction
    abs                  (3)  - compute the absolute value of an integer
    accept               (2)  - accept a connection on a socket
    access               (2)  - check user’s permissions for a file

Interesting, eh? This leads me to conclude that apropos is a synonym for grep -i, and sure enough, grep -i help whatis produces the exact same results we saw earlier. Try it!

2. More interestingly, we can now extract the different sections of the database and see how many commands there are in each section.

To accomplish this, I want to split the line at the beginning parenthesis, then again at the ending parenthesis, and leave just the value within. This can be done with two calls to cut, the first specifying the open paren delimiter, the second the closing paren. Here’s what the first invocation does:

    # cut -d( -f2 < whatis | head -5
    1)  - convert Sony Mavica .411 image to PPM
    1)  - Awk to Perl translator
    1)  - format files for printing on a PostScript printer
    8)  - Apache HTTP server benchmarking tool
    3pm)  - create an abbreviation table from a list

and the second, added in the middle of the pipe:

     cut -d( -f2 < whatis | cut -d) -f1 | head -5
    1
    1
    1
    8
    3pm

Now, finally, just a call to sort to sort them all, and uniq with the -c flag to get a final output count:

    # cut -d( -f2 < whatis | cut -d) -f1 | sort | uniq -c
         14
       1405 1
          6 1m
         39 1ssl
        254 2
       8272 3
        400 3pm
        335 3qt
        657 3ssl
         77 3t
         61 3thr
       3603 3x
         36 4
        146 5
          1 5ssl
          3 6
         67 7
          1 7ssl
        380 8
         67 l
        446 n
          1 Paranoia release III
          1 xnmap

That’s your answer. Ignore the odd ones (for example, Paranoia release III), and you can see that there are 1,405 section 1 commands, 380 section 8 commands, and over 13,000 different commands and functions for system programmers on a Linux system. No wonder it’s not easy to program a Unix system!

This section is not only a good example of how you can combine Unix commands to produce useful results, but how you can also get quite sidetracked. Even the author finds it occasionally difficult to avoid poking around and learning more about the system!

Finding Commands

The apropos command offers a very helpful way to navigate through the man commands based on the one-line command summaries, but there are other ways to explore the commands available on your Unix system. Most notably, which will search your path and tell you what file is to be executed for a given command name, and locate is a fast way to try to match a pattern against a list of all filenames on your system.

The latter, however, is really a special purpose variation of the powerful general purpose find command, which we’ll cover in greater detail later in the book.

Task 2.3: Which Command Are You Running?

The first step in debugging any problem in Unix is to ensure that your PATH is correct, then to make sure that the version of the command you think you’re running is the version that is being invoked.

All command shells build what’s called a hash table of commands, a quickly-searched list of filenames located in each of the directories specified in the PATH environment variable. If there are collisions (for example, two directories have the same filename), the directory referenced earlier in the PATH wins.

1. Let’s start by finding out what our PATH is, and then seeing what version of man we’re running when we use the man command:

    # echo $PATH
    /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/taylor/bin
    # which man
    /usr/bin/man

You can see that our Linux path consists of /usr/local/bin, /bin, /usr/bin, /usr/X11R6/bin (the X Window System files), and /home/taylor/bin (my personal additions to the Unix command world). Notice there’s no . entry, and that my personal version of any command will not supplant the standard version because my directory comes last in the PATH. To have it supplant built-in commands, I’d need to have it appear first in the PATH instead.

2. Some versions of which know about aliases, whereas others don’t. Both Linux and Darwin have an alias of ll=″ls -l″, but the difference in which output is interesting:

Linux:

    # alias ll
    alias ll=’/bin/ls -l’
    # which ll
    which: no ll in (/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:
    /home/taylor/bin)

Darwin:

    # alias ll
    ls -lag !* | more
    # which ll
    ll:      aliased to ls -lag !* | more

Some of this output is directly related to what shell the user is running—often C Shell (csh) will include alias parsing, whereas the Bourne-Again Shell (bash) won’t.

Solaris behaves exactly like Linux in this example, happily displaying the alias for ll, but with a which command that is unaware of shell aliases.

The puzzle here is that if we’re using Linux, we now have an example of a command that works—ll—but isn’t in our path. Most mysterious if you don’t remember the alias command, too.

3. But then again, maybe there is an ll command, and we’re just not seeing it with the which command. To search quickly through all the filenames on the system, the locate command is our choice; though like much of Unix, it takes a little bit of thinking to figure out how to use it most appropriately:

    # locate ll | wc -l
       4021

Alright, more than 4,000 filenames match the double-l sequence. Of course, you might well have a different number due to the specific packages you opted to install on your system. No worries! Instead, let’s try prefixing it with a slash:

    # locate /ll | wc -l
         11

Eleven is a much more manageable number, so let’s see what they are:

    # locate /ll
    /usr/share/doc/HTML/en/kdevelop/reference/C/CONTRIB/SNIP/ll_msort.c
    /usr/share/doc/HTML/en/kdevelop/reference/C/CONTRIB/SNIP/ll_qsort.c
    /usr/share/man/man2/llseek.2.gz
    /usr/share/man/man3/llabs.3.gz
    /usr/share/man/man3/llrint.3.gz
    /usr/share/man/man3/llrintf.3.gz
    /usr/share/man/man3/llrintl.3.gz
    /usr/share/man/man3/llround.3.gz
    /usr/share/man/man3/llroundf.3.gz
    /usr/share/man/man3/llroundl.3.gz
    /usr/share/man/mann/llength.n.gz

Interesting, but there’s no sign of an ll command in the entire system.

The locate command can also show you where commands you suspect are part of Unix are located. For example:

    # locate chess
    /usr/share/ghostscript/6.51/examples/chess.ps
    /usr/share/licq/qt-gui/icons.computer/chess.xpm
    # locate cribbage
    /home/taylor/bin/cribbage
    /home/taylor/DEMO/Src/cribbage.c

Neat! As you can see, locate casts a net across the entire file system, including individual user files. Very helpful.

One of the first tasks of any system administrator is to be able to figure out what’s going on when a user complains of a problem (or when encountering your own problem). To do that, it’s critical to ascertain what command the user is invoking and whether that’s the correct version for the system. That’s the province of the helpful which command. When that fails, locate can be used to see if there’s a match, and if you really need to roll out the power tools, find is a lifesaver, as you’ll see throughout this book.

Digging Around in Executable Binaries

The combination of which to identify commands, file to ascertain what kind of command it is, the man page, and even viewing the file itself (if it’s a script) can reveal a lot about your system. Sometimes, though, the file in question might be a compiled binary, and the source might not be handy. That’s where the strings command can be very helpful.

Task 2.4: The strings Command

The strings command is an unsung hero of sysadmins, just as the file command is such a winner, even though it’s rarely mentioned in system administration books. What strings does is read through the contents of any file, looking for printable ASCII sequences. If it finds one, it displays it on the screen.

Given this behavior, it’s quite easy to feed the output to grep and extract useful information from the executable binary itself, including what configuration files it uses, and more.

1. Let’s have a look at the man command itself. To start, I’ll use which to see where the command lives, then I’ll use file to see whether it’s a script or executable:

    # which -a man
    /usr/bin/man
    # file /usr/bin/man
    /usr/bin/man: ELF 32-bit LSB executable, Intel 80386, version 1,
    dynamically linked (uses shared libs), stripped

Now that we know it’s a binary, let’s peek inside with the strings command:

    # strings /usr/bin/man | head
    /lib/ld-linux.so.2
    __gmon_start__
    libc.so.6
    strcpy
    ioctl
    getgid
    printf
    stdout
    vsprintf
    geteuid

Not too exciting,  but if we grep this for the sequence conf …

    # strings /usr/bin/man | grep conf
    [no configuration file]
    /usr/share/misc/man.config
    /usr/share/misc/man.conf
    /usr/lib/man.config
    /usr/lib/man.conf
    /etc/man.conf
    /etc/man.config
    Reading config file %s
      C file   : use ‘file’ as configuration file
    man-config.c: internal error: string %s not found
    Unrecognized line in config file (ignored)
    but the configuration file does not define COMPRESS.
    Warning: cannot open configuration file %s
    is not in the config file
    is in the config file
    Line too long in config file
    Error parsing config file

This is the kind of output that can prove very useful. Here you can see that the man command uses a configuration file, and that it can appear in any of a number of different places:

    /usr/share/misc/man.config
    /usr/share/misc/man.conf
    /usr/lib/man.config
    /usr/lib/man.conf
    /etc/man.conf
    /etc/man.config

It would be a matter of a quick ls or two to find out which is the actual file on this system; then we’d be learning how to configure man, even though the man page only mentions the configuration file in passing.

Although the Unix documentation can reveal quite a bit about how to work with different commands, sometimes popping open the proverbial hood to tinker on the engine is necessary. With shell and Perl scripts, that’s easy, but if you encounter a compiled binary, the strings command can be an invaluable addition to your toolbox!

Summary

This hour has focused on demonstrating how to use common Unix tools like grep, cut, and head to fine-tune the online documentation tools. You have also seen how SEE ALSO and FILES sections in man pages offer great assistance in figuring out how commands work and how to configure them.

As somewhat of a sidetrack, you saw how commands rely on each other within Unix, and how specifically the apropos command relies on the database that the whatis command uses, and is created by makewhatis. Building that database, we encountered an error condition, diagnosed the problem, postulated a couple of possible solutions, and implemented the best of them, permanently fixing the command.

Finally, the other important aspect of this chapter is that it demonstrates how this book is focused on teaching you how to explore Unix and find solutions for yourself, rather than listing all the command flags for each command, or even ensuring that every possible use of every possible command has been enumerated.

This problem-solving orientation will prove a great boon as you go through these 24 hours’ worth of material, and you’ll have a much greater degree of comfort on new and alien Unixes than if you memorized lots of Unix flavor-specific commands.

Q&A

Q Is it a wizard or a guru who knows how to find the answer to everything?

A A guru. A wizard is someone who can do things as if they’re magic, but can’t ever teach anyone else what they’re doing.

Q Why do some Unix systems have a command apropos if it’s really just an alias to the grep command?

A As is common with Unix, some development teams err on the side of offering maximal usability, enabling users to just start typing and go, whereas others prefer the simple elegance of core commands and nothing else.

Workshop

Quiz

1. No cheating now: What do you think the whatis command does?

2. Write an equivalent of whatis using grep. Think carefully about the transformation you want to make to the given pattern before searching through the whatis database.

3. Are system administrators more likely to get sidetracked if they’re working on an OS like Windows? Why, or why not?

4. What command is in the man pages section ″Paranoia″?

5. How many section 1 commands do you have on your system? Can you think of another way to figure that number out?

Answers

1. whatis summarizes in a single line of output the purpose of any Unix command specified on the command line.

2. The equivalent of whatis floppy would be grep -iE ′^floppy(′ /usr/man/whatis.db (the exact syntax might change based on where your system stores the whatis database). Note that you need to construct a regular expression that ensures whatis cp doesn’t match uucp or other commands containing the letters cp. The -i flag ignores case, and the -E indicates that a regular expression will follow.

3. Well, you can probably be sidetracked on any operating system if you’re the sort to poke around and explore, but generally there’s so much power underneath the hood on a typical Unix system that I think you’re more likely to get sidetracked than if you’re in the constrained and confined world of Windows.

4. On Red Hat Linux 7.2, searching for Paranoia in the whatis.db database reveals that it’s the cdparanoia command, which is described as ″an audio CD-reading utility which includes extra data verification features.″

5. One obvious strategy for this is grep ′(1)’ /usr/man/whatis.db | wc -l, but there are a variety of commands that are officially in section 1, but end up listed as 1L or 1B or some other such cryptic subsection. The best strategy, therefore, if you want to exploit the whatis database, is to use grep ′(1’ /usr/man/whatis.db | wc -l. Another way to ascertain this number that’s even more direct is to ls /usr/man/man1 | wc -l (though you’ll end up with more than you expect, because some man pages are symbolically linked to more than one command name for historical reasons).

In the next hour, you’ll learn how to explore the file allocation information within Unix through use of the du and df commands. We’ll also look at how to create a simple shell script that will report the size of every user’s home directory, sorted from largest to smallest.