The sh utility and the set special built-in utility share a
common set of options.
The name IFS was originally an abbreviation of ``Input Field
Separators''; however, this name is misleading as the IFS
characters are actually used as field terminators. One
justification for ignoring the contents of IFS upon entry to the
script, beyond security considerations, is to assist possible
future shell compilers. Allowing IFS to be imported from the
environment prevents many optimizations that might otherwise be
performed via dataflow analysis of the script itself.
The text in the STDIN section about non-blocking reads concerns
an instance of sh that has been invoked, probably by a C-language
program, with standard input that has been opened using the
O_NONBLOCK flag; see open() in the System Interfaces volume of
POSIX.1‐2017. If the shell did not reset this flag, it would
immediately terminate because no input data would be available
yet and that would be considered the same as end-of-file.
The options associated with a restricted shell (command name rsh
and the -r option) were excluded because the standard developers
considered that the implied level of security could not be
achieved and they did not want to raise false expectations.
On systems that support set-user-ID scripts, a historical
trapdoor has been to link a script to the name -i. When it is
called by a sequence such as:
sh -
or by:
#! usr/bin/sh -
the historical systems have assumed that no option letters
follow. Thus, this volume of POSIX.1‐2017 allows the single
<hyphen-minus> to mark the end of the options, in addition to the
use of the regular "--" argument, because it was considered that
the older practice was so pervasive. An alternative approach is
taken by the KornShell, where real and effective user/group IDs
must match for an interactive shell; this behavior is
specifically allowed by this volume of POSIX.1‐2017.
Note: There are other problems with set-user-ID scripts that the
two approaches described here do not resolve.
The initialization process for the history file can be dependent
on the system start-up files, in that they may contain commands
that effectively preempt the user's settings of HISTFILE and
HISTSIZE. For example, function definition commands are recorded
in the history file, unless the set -o nolog option is set. If
the system administrator includes function definitions in some
system start-up file called before the ENV file, the history file
is initialized before the user gets a chance to influence its
characteristics. In some historical shells, the history file is
initialized just after the ENV file has been processed.
Therefore, it is implementation-defined whether changes made to
HISTFILE after the history file has been initialized are
effective.
The default messages for the various MAIL-related messages are
unspecified because they vary across implementations. Typical
messages are:
"you have mail\n"
or:
"you have new mail\n"
It is important that the descriptions of command line editing
refer to the same shell as that in POSIX.1‐2008 so that
interactive users can also be application programmers without
having to deal with programmatic differences in their two
environments. It is also essential that the utility name sh be
specified because this explicit utility name is too firmly rooted
in historical practice of application programs for it to change.
Consideration was given to mandating a diagnostic message when
attempting to set vi-mode on terminals that do not support
command line editing. However, it is not historical practice for
the shell to be cognizant of all terminal types and thus be able
to detect inappropriate terminals in all cases. Implementations
are encouraged to supply diagnostics in this case whenever
possible, rather than leaving the user in a state where editing
commands work incorrectly.
In early proposals, the KornShell-derived emacs mode of command
line editing was included, even though the emacs editor itself
was not. The community of emacs proponents was adamant that the
full emacs editor not be standardized because they were concerned
that an attempt to standardize this very powerful environment
would encourage vendors to ship strictly conforming versions
lacking the extensibility required by the community. The author
of the original emacs program also expressed his desire to omit
the program. Furthermore, there were a number of historical
systems that did not include emacs, or included it without
supporting it, but there were very few that did not include and
support vi. The shell emacs command line editing mode was
finally omitted because it became apparent that the KornShell
version and the editor being distributed with the GNU system had
diverged in some respects. The author of emacs requested that the
POSIX emacs mode either be deleted or have a significant number
of unspecified conditions. Although the KornShell author agreed
to consider changes to bring the shell into alignment, the
standard developers decided to defer specification at that time.
At the time, it was assumed that convergence on an acceptable
definition would occur for a subsequent draft, but that has not
happened, and there appears to be no impetus to do so. In any
case, implementations are free to offer additional command line
editing modes based on the exact models of editors their users
are most comfortable with.
Early proposals had the following list entry in vi Line Editing
Insert Mode:
\ If followed by the erase or kill character, that character
shall be inserted into the input line. Otherwise, the
<backslash> itself shall be inserted into the input line.
However, this is not actually a feature of sh command line
editing insert mode, but one of some historical terminal line
drivers. Some conforming implementations continue to do this when
the stty iexten flag is set.
In interactive shells, SIGTERM is ignored so that kill 0 does not
kill the shell, and SIGINT is caught so that wait is
interruptible. If the shell does not ignore SIGTTIN, SIGTTOU, and
SIGTSTP signals when it is interactive and the -m option is not
in effect, these signals suspend the shell if it is not a session
leader. If it is a session leader, the signals are discarded if
they would stop the process, as required by the System Interfaces
volume of POSIX.1‐2017, Section 2.4.3, Signal Actions for
orphaned process groups.
