Shell Programming FAQs
- Shell and Command Questions
- Variable and Argument Questions
- File and Directory Questions
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Each of the previous chapters has focused on an individual topic in shell programming, such as variables, loops, or debugging. As you progressed through the book, you worked on problems that required knowledge from previous chapters. This chapter takes a slightly different approach by trying to answer some frequently asked shell programming questions. Specifically, this chapter covers questions from three main areas of shell programming:
-
The shell and commands
-
Variables and arguments
-
Files and directories
Each section includes several common shell programming questions (and answers!). These questions are designed to help you solve or avoid common problems. Some of the questions provide deeper background information about UNIX, whereas others illustrate concepts covered in previous chapters.
Shell and Command Questions
This section covers some of the common questions about the shell itself and how the shell executes commands.
Why does #!/bin/sh have to be the first line of my scripts?
Chapter 2, "Script Basics," stated that #!/bin/sh must be the first line in your script to ensure that the correct shell is used to execute your script. This line must be the first line in your shell script because of the underlying mechanism used by a shell to execute commands.
When you ask a shell to execute a command as follows
$ date
The shell uses the exec system call to ask the UNIX kernel to execute the command you requested. System calls are C language functions built in to the UNIX kernel that enable you to access features of the kernel. The shell passes the name of the command that should be executed to the exec system call. This system call reads the first two characters in a file to determine how to execute the command. In the case of shell scripts, the first two characters are #!, indicating that the script needs to be interpreted by another program instead of executed directly. The rest of the line is treated as the name of the interpreter to use.
Usually the interpreter is /bin/sh, but you can also specify options to the shell on this line. Sometimes options such as -x or -nv are specified to enable debugging. This also enables you to write scripts tuned for a particular shell such as ksh, bash, or zsh by using /bin/ksh, /bin/bash, or /bin/zsh instead of /bin/sh. (The exact path to the shell may vary from system to system.)
How can I access the name of the current shell in my initialization scripts?
In your shell initialization scripts, the name of the current shell is stored in the variable $0.
Users who have a single .profile that is shared by sh, ksh, and bash use this variable in conjunction with a case statement near the end of this file to execute additional shell–specific startups. For example, you can use the following case statement in your .profile to set up the prompt, PS1, differently depending on the shell:
case "$0" in *bash) PS1="\t \h \#$ " ;; *ksh) PS1="´uname -n´ !$ " ;; *sh) PS1="´uname -n´$ " ;; esac export PS1
Here, you have specified the shells as *bash, *ksh, and *sh, because some versions of UNIX place the - character in front of login shells, but not in front of other shells.
How do I tell whether the current shell is interactive or non-interactive?
Some scripts need the capability to determine whether they are running in an interactive shell or a non-interactive shell. Usually this is restricted to your shell initialization scripts because you don't want to perform a full-blown initialization every time these scripts execute. Some other examples include scripts that can run from the at or cron commands.
You can tell whether a shell is interactive by checking the value of the variable $-. If the value contains the letter i, the shell is interactive. Otherwise, it is non-interactive. The following case statement illustrates one method for checking the value of $-:
case $- in
*i*) : # interactive
# commands for interactive shells go here
;;
*) : # non interactive
# commands for non-interactive shells go here
;;
esac
The following example illustrates the use of this case statement:
isInteractive () {
case $- in
*i* ) echo Interactive ; ec=0 ;;
*) echo Non-Interactive ; ec=1 ;;
esac
return $ec
}
This function can be used to determine whether the current shell is interactive.
How do I discard the output of a command?
Sometimes you will need to execute a command, but you don't want the output displayed to the screen. In these cases you can discard the output by redirecting it to the file /dev/null:
cmd > /dev/null
Here cmd is the name of the command you want to execute. The file is a special file (called the bit bucket) that automatically discards all its input. For example, the following command discards the output of the grep command:
if grep soda /etc/hosts > /dev/null ; then echo 'Soda found!' fi
Because commands also output error messages, you will often have to redirect STDERR to /dev/null. If you do not redirect STDERR, when a command fails your script will display that error message, which can be confusing to a user. To discard both output of a command and its error output, you can redirect STDERR (file descriptor 2) to STDOUT (file descriptor 1) and redirect STDOUT to /dev/null as follows:
cmd > /dev/null 2>&1
The following example illustrates redirecting both STDERR and STDOUT to /dev/null:
if grep soda /etc/hosts > /dev/null 2>&1 ; then echo 'Soda found!' fi
How can I display messages on STDERR?
You can display a message on to STDERR by redirecting STDIN into STDERR as follows:
echo msg 1>&2
Here msg is the message you want to display. For example, the output of the following command is displayed on STDERR instead of STDOUT:
$ echo 'This is an error message' 1>&2
If you are interested in shell functions that perform additional formatting, please consult Chapter 21, "Problem Solving with Functions," which covers several shell functions that display messages on to STDERR.
How can I determine whether a command executed successfully?
You can determine whether a command executed successful by checking the command's exit code, which the shell stores in the variable $?. By convention, the exit code of a successful command is 0. A nonzero exit code indicates a failure.
An if statement of the following form is often used to check whether a command executed successfully:
cmd if [ $? -eq 0 ] ; then : # cmd successful else : # cmd failed fi
Here cmd is a command whose exit status needs to be checked. The following example illustrates this:
grep soda /etc/hosts > /dev/null 2>&1 if [ $? -ne 0 ] ; then echo "Soda Found!" else echo "No entry in /etc/hosts for soda." fi
Here you execute a grep command and then check the exit status of that command using the value stored in $?.
How do I determine whether the shell can find a particular command?
You can check to make sure that the shell can find a command or shell function by using the type command covered in Chapter 18, "Other Tools":
type cmd > /dev/null 2>&1 if [ $? -eq 0 ] ; then : # we have cmd, execute commands that require cmd else : # we don't have cmd, execute alternate commands (if any) fi
Here cmd is the name of the command you want check for. The type command is a built-in in sh, bash, and zsh. In ksh, type is usually an alias, whence -v.
An alternate form omits the explicit checking of the exit status stored in $?:
if type cmd > /dev/null 2>&1 ; then : # we have cmd, execute commands that require cmd else : # we don't have cmd, execute alternate commands (if any) fi
This form relies on the fact that if interprets an exit code of 0 as true.
The following example illustrate a possible use of the type command:
if type basename > /dev/null 2>&1 ; then
: # we have basename, nothing to do
else
# we don't have basename, define a function that
# implements the same functionality
basename () {
if [ -n "$1" ] ; then
echo "$1" | sed -e 's/^.*\///'
else
echo "Usage: basename [file]" 1>&2
return 1
fi
return 0
}
fi
This if statement checks to see if basename exists; if it does not, a function implementation is defined.
Can I use the && and || operators to conditionally execute commands?
The && and || operators are often used to conditionally execute commands. The basic syntax for using these operators is
cmd1 op cmd2
Here cmd1 and cmd2 are two commands and op is the && or || operator. If op is && then cmd2 is executed only when cmd1 is successful. If op is || then cmd2 is executed only when cmd1 fails.
The following example illustrates the use of &&:
type bash > /dev/null 2>&1 &&
{ HAVE_BASH=1 ; echo "bash found" ; }
This command is equivalent to the following if statement:
type bash > /dev/null 2>&1 if [ $? -eq 0 ] ; then HAVE_BASH=1 echo "bash found" fi
The following example illustrates the use of ||:
grep soda /etc/hosts > /dev/null 2>&1 || echo 'Soda not found!'This command is equivalent to the following if statement:
grep soda /etc/hosts > /dev/null 2>&1 if [ $? -ne 0 ] ; then echo 'Soda not found!' fi
How do I execute some commands in a separate shell?
The easiest way to execute a set of commands in a separate shell is to use the parentheses, (), as follows:
( list ; )
Here list is executed in a separate shell (called a sub-shell) and any changes the commands in list make to the working directory (via calls to cd) or environment variables will not affect the values in the script that invoked list.
As an example, the following function allows you to determine the absolute pathname of a directory without altering your current working directory:
abspath () { ( cd "$1" && pwd ; ) ; }