Classic Shell Scripting - Arnold Robbins [166]
We showed how to create unique temporary filenames with the shell process ID variable, $$, with the mktemp utility and a do-it-yourself sampling of streams of random numbers. The computing world can be a hostile environment, so it is worth protecting your programs from attack by giving their temporary files unique and unguessable names.
We described the locate and slocate commands for fast lookup of filenames in a regularly updated database constructed by complete scans of the filesystem. When you know part or all of a filename and just want to find where it is in the filesystem, locate is generally the best way to track it down, unless it was created after the database was constructed.
The type command is a good way to find out information about shell commands, and our pathfind script from Chapter 8 provides a more general solution for locating files in a specified directory path.
We took several pages to explore the powerful find command, which uses brute-force filesystem traversal to find files that match user-specified criteria. Nevertheless, we still had to leave many of its facilities for you to discover on your own from its manual pages and the extensive manual for GNU find.
We gave a brief treatment of xargs, another powerful command for doing operations on lists of files, often produced upstream in a pipeline by find. Not only does this overcome command-line length restrictions on many systems, but it also gives you the opportunity to insert additional filters in the pipeline to further control what files are ultimately processed.
The df and du commands report the space used in filesystems and directory trees. Learn them well, because you may use them often.
We wrapped up with a description of commands for comparing files, applying patches, generating file checksums, and validating digital signatures.
Chapter 11. Extended Example: Merging User Databases
By now, we've come a long way and seen a number of shell scripts. This chapter aims to tie things together by writing shell programs to solve a moderately challenging task.
The Problem
The Unix password file, /etc/passwd, has shown up in several places throughout the book. System administration tasks often revolve around manipulation of the password file (and the corresponding group file, /etc/group). The format is well known:[1]
tolstoy:x:2076:10:Leo Tolstoy:/home/tolstoy:/bin/bash
There are seven fields: username, encrypted password, user ID number (UID), group ID number (GID), full name, home directory, and login shell. It's a bad idea to leave any field empty: in particular, if the second field is empty, the user can log in without a password, and anyone with access to the system or a terminal on it can log in as that user. If the seventh field (the shell) is left empty, Unix defaults to the Bourne shell, /bin/sh.
As is discussed in detail in Appendix B, it is the user and group ID numbers that Unix uses for permission checking when accessing files. If two users have different names but the same UID number, then as far as Unix knows, they are identical. There are rare occasions when you want such a situation, but usually having two accounts with the same UID number is a mistake. In particular, NFS requires a uniform UID space; user number 2076 on all systems accessing each other via NFS had better be the same user (tolstoy), or else there will be serious security problems.
Now, return with us for a moment to yesteryear (around 1986), when Sun's NFS was just beginning to become popular and available on non-Sun systems. At the time, one of us was a system administrator of two separate 4.2 BSD Unix minicomputers. These systems communicated via TCP/IP, but did not have NFS. However, a new OS vendor was scheduled to make 4.3 BSD + NFS available for these systems. There were a number of users with accounts on both systems; typically the username was the same, but the UID wasn't! These systems were soon to be sharing filesystems via NFS; it was imperative that their UID spaces be merged. The task was to write