Classic Shell Scripting - Arnold Robbins [87]
The purpose of tilde expansion is to replace a symbolic representation for a user's home directory with the actual path to that directory. The user may be named either explicitly, or implicitly, in which case it is the current user running the program:
$ vi ~/.profile
Same as vi $HOME/.profile
$ vi ~tolstoy/.profile
Edit user tolstoy's .profile file
In the first case, the shell replaces the ~ with $HOME, the current user's home directory. In the second case, the shell looks up user tolstoy in the system's password database, and replaces ~tolstoy with tolstoy's home directory, whatever that may be.
* * *
Tip
Tilde expansion first appeared in the Berkeley C shell, csh. It was intended primarily as an interactive feature. It proved to be very popular, and was adopted by the Korn shell, bash, and just about every other modern Bourne-style shell. It thus also found its way into the POSIX standard.
However (and there's always a "however"), many commercial Unix Bourne shells don't support it. Thus, you should not use tilde expansion inside a shell script that has to be portable.
* * *
Tilde expansion has two advantages. First, it is a concise conceptual notation, making it clear to the reader of a shell script what's going on. Second, it avoids hardcoding pathnames into a program. Consider the following script fragment:
printf "Enter username: " Print prompt
read user Read user
vi /home/$user/.profile Edit user's .profile file
...
The preceding program assumes that all user home directories live in /home. If this ever changes (for example, by division of users into subdirectories based on department), then the script will have to be rewritten. By using tilde expansion, this can be avoided:
printf "Enter username: " Print prompt
read user Read user
vi ~$user/.profile Edit user's .profile file
...
Now the program works correctly, no matter where the user's home directory is.
Many shells, such as ksh88, ksh93, bash, and zsh, provide additional tilde expansions: see Section 14.3.7, for more information.
Wildcarding
One of the shell's services is to look for special characters in filenames. When it finds these characters, it treats them as patterns to be matched: i.e., a specification of a set of files whose names all match the given pattern. The shell then replaces the pattern on the command line with the sorted set of filenames that match the pattern.[4]
If you've had any exposure to even the simple command-line environment available under MS-DOS, you're probably familiar with the *.* wildcard that matches all filenames in the current directory. Unix shell wildcards are similar, but much more powerful. The basic wildcards are listed in Table 7-5.
Table 7-5. Basic wildcards
Wildcard
Matches
?
Any single character
*
Any string of characters
[ set ]
Any character in set
[! set ]
Any character not in set
The ? wildcard matches any single character, so if your directory contains the files whizprog.c, whizprog.log, and whizprog.o, then the expression whizprog.? matches whizprog.c and whizprog.o, but not whizprog.log.
The asterisk (*) is more powerful and far more widely used; it matches any string of characters. The expression whizprog.* matches all three files in the previous paragraph; web designers can use the expression *.html to match their input files.
* * *
Tip
MS-DOS, MS-Windows, and OpenVMS users should note that there is nothing special about the dot (.) in Unix filenames (aside from the leading dot, which "hides" the file); it's just another character. For example, ls * lists all files in the current directory; you don't need *.* as you do on other systems.
* * *
The remaining wildcard is the set construct. A set is a list of characters (e.g., abc), an inclusive range (e.g., a-z), or some combination of the two. If you want the dash character to be part of a list, just list it first or last. Table