The set -- form is listed specifically in the SYNOPSIS even
though this usage is implied by the Utility Syntax Guidelines.
The explanation of this feature removes any ambiguity about
whether the set -- form might be misinterpreted as being
equivalent to set without any options or arguments. The
functionality of this form has been adopted from the KornShell.
In System V, set -- only unsets parameters if there is at least
one argument; the only way to unset all parameters is to use
shift. Using the KornShell version should not affect System V
scripts because there should be no reason to issue it without
arguments deliberately; if it were issued as, for example:
set -- "$@"
and there were in fact no arguments resulting from "$@",
unsetting the parameters would have no result.
The set + form in early proposals was omitted as being an
unnecessary duplication of set alone and not widespread
historical practice.
The noclobber option was changed to allow set -C as well as the
set -o noclobber option. The single-letter version was added so
that the historical "$-" paradigm would not be broken; see
Section 2.5.2, Special Parameters.
The description of the -e option is intended to match the
behavior of the 1988 version of the KornShell.
The -h flag is related to command name hashing. See hash(1p).
The following set flags were omitted intentionally with the
following rationale:
-k The -k flag was originally added by the author of the
Bourne shell to make it easier for users of pre-release
versions of the shell. In early versions of the Bourne
shell the construct set name=value had to be used to assign
values to shell variables. The problem with -k is that the
behavior affects parsing, virtually precluding writing any
compilers. To explain the behavior of -k, it is necessary
to describe the parsing algorithm, which is implementation-
defined. For example:
set -k; echo name=value
and:
set -k
echo name=value
behave differently. The interaction with functions is even
more complex. What is more, the -k flag is never needed,
since the command line could have been reordered.
-t The -t flag is hard to specify and almost never used. The
only known use could be done with here-documents. Moreover,
the behavior with ksh and sh differs. The reference page
says that it exits after reading and executing one command.
What is one command? If the input is date;date, sh executes
both date commands while ksh does only the first.
Consideration was given to rewriting set to simplify its
confusing syntax. A specific suggestion was that the unset
utility should be used to unset options instead of using the non-
getopt()-able +option syntax. However, the conclusion was reached
that the historical practice of using +option was satisfactory
and that there was no compelling reason to modify such widespread
historical practice.
The -o option was adopted from the KornShell to address user
needs. In addition to its generally friendly interface, -o is
needed to provide the vi command line editing mode, for which
historical practice yields no single-letter option name.
(Although it might have been possible to invent such a letter, it
was recognized that other editing modes would be developed and -o
provides ample name space for describing such extensions.)
Historical implementations are inconsistent in the format used
for -o option status reporting. The +o format without an option-
argument was added to allow portable access to the options that
can be saved and then later restored using, for instance, a dot
script.
Historically, sh did trace the command set +x, but ksh did not.
The ignoreeof setting prevents accidental logouts when the end-
of-file character (typically <control>‐D) is entered. A user
shall explicitly exit to leave the interactive shell.
The set -m option was added to apply only to the UPE because it
applies primarily to interactive use, not shell script
applications.
The ability to do asynchronous notification became available in
the 1988 version of the KornShell. To have it occur, the user had
to issue the command:
trap "jobs -n" CLD
The C shell provides two different levels of an asynchronous
notification capability. The environment variable notify is
analogous to what is done in set -b or set -o notify. When set,
it notifies the user immediately of background job completions.
When unset, this capability is turned off.
The other notification ability comes through the built-in utility
notify. The syntax is:
notify [%job ... ]
By issuing notify with no operands, it causes the C shell to
notify the user asynchronously when the state of the current job
changes. If given operands, notify asynchronously informs the
user of changes in the states of the specified jobs.
To add asynchronous notification to the POSIX shell, neither the
KornShell extensions to trap, nor the C shell notify environment
variable seemed appropriate (notify is not a proper POSIX
environment variable name).
The set -b option was selected as a compromise.
The notify built-in was considered to have more functionality
than was required for simple asynchronous notification.
Historically, some shells applied the -u option to all parameters
including $@ and $*. The standard developers felt that this was
a misfeature since it is normal and common for $@ and $* to be
used in shell scripts regardless of whether they were passed any
arguments. Treating these uses as an error when no arguments are
passed reduces the value of -u for its intended purpose of
finding spelling mistakes in variable names and uses of unset
positional parameters.
