обрабатывать сообщения (process messages)
Обоснование (Rationale)
The standard developers felt strongly that a method for
applications to send messages to specific users was necessary.
The obvious example is a batch utility, running non-
interactively, that wishes to communicate errors or results to a
user. However, the actual format, delivery mechanism, and method
of reading the message are clearly beyond the scope of this
volume of POSIX.1‐2017.
The intent of this command is to provide a simple, portable
interface for sending messages non-interactively. It merely
defines a ``front-end'' to the historical mail system. It is
suggested that implementations explicitly denote the sender and
recipient in the body of the delivered message. Further
specification of formats for either the message envelope or the
message itself were deliberately not made, as the industry is in
the midst of changing from the current standards to a more
internationalized standard and it is probably incorrect, at this
time, to require either one.
Implementations are encouraged to conform to the various delivery
mechanisms described in the CCITT X.400 standards or to the
equivalent Internet standards, described in Internet Request for
Comment (RFC) documents RFC 819, RFC 920, RFC 921, RFC 1123, and
RFC 5322 (which succeeded RFC 822).
Many historical systems modified each body line that started with
From by prefixing the 'F' with '>'. It is unnecessary, but
allowed, to do that when the string does not follow a blank line
because it cannot be confused with the next header.
The edit and visual commands merely edit the specified messages
in a temporary file. They do not modify the contents of those
messages in the mailbox; such a capability could be added as an
extension, such as by using different command names.
The restriction on a subject line being {LINE_MAX}-10 bytes is
based on the historical format that consumes 10 bytes for
Subject: and the trailing <newline>. Many historical mailers
that a message may encounter on other systems are not able to
handle lines that long, however.
Like the utilities logger and lp, mailx admittedly is difficult
to test. This was not deemed sufficient justification to exclude
this utility from this volume of POSIX.1‐2017. It is also
arguable that it is, in fact, testable, but that the tests
themselves are not portable.
When mailx is being used by an application that wishes to receive
the results as if none of the User Portability Utilities option
features were supported, the DEAD environment variable must be
set to /dev/null. Otherwise, it may be subject to the file
creations described in mailx ASYNCHRONOUS EVENTS. Similarly, if
the MAILRC environment variable is not set to /dev/null,
historical versions of mailx and Mail read initialization
commands from a file before processing begins. Since the
initialization that a user specifies could alter the contents of
messages an application is trying to send, such applications must
set MAILRC to /dev/null.
The description of LC_TIME uses ``may affect'' because many
historical implementations do not or cannot manipulate the date
and time strings in the incoming mail headers. Some headers found
in incoming mail do not have enough information to determine the
timezone in which the mail originated, and, therefore, mailx
cannot convert the date and time strings into the internal form
that then is parsed by routines like strftime() that can take
LC_TIME settings into account. Changing all these times to a
user-specified format is allowed, but not required.
The paginator selected when PAGER is null or unset is partially
unspecified to allow the System V historical practice of using pg
as the default. Bypassing the pagination function, such as by
declaring that cat is the paginator, would not meet with the
intended meaning of this description. However, any ``portable
user'' would have to set PAGER explicitly to get his or her
preferred paginator on all systems. The paginator choice was made
partially unspecified, unlike the VISUAL editor choice (mandated
to be vi) because most historical pagers follow a common theme of
user input, whereas editors differ dramatically.
Options to specify addresses as cc (carbon copy) or bcc (blind
carbon copy) were considered to be format details and were
omitted.
A zero exit status implies that all messages were sent, but it
gives no assurances that any of them were actually delivered.
The reliability of the delivery mechanism is unspecified and is
an appropriate marketing distinction between systems.
In order to conform to the Utility Syntax Guidelines, a solution
was required to the optional file option-argument to -f. By
making file an operand, the guidelines are satisfied and users
remain portable. However, it does force implementations to
support usage such as:
mailx -fin mymail.box
The no name method of unsetting variables is not present in all
historical systems, but it is in System V and provides a logical
set of commands corresponding to the format of the display of
options from the mailx set command without arguments.
The ask and asksub variables are the names selected by BSD and
System V, respectively, for the same feature. They are synonyms
in this volume of POSIX.1‐2017.
The mailx echo command was not documented in the BSD version and
has been omitted here because it is not obviously useful for
interactive users.
The default prompt on the System V mailx is a <question-mark>, on
BSD Mail an <ampersand>. Since this volume of POSIX.1‐2017 chose
the mailx name, it kept the System V default, assuming that BSD
users would not have difficulty with this minor incompatibility
(that they can override).
The meanings of r and R are reversed between System V mailx and
SunOS Mail. Once again, since this volume of POSIX.1‐2017 chose
the mailx name, it kept the System V default, but allows the
SunOS user to achieve the desired results using flipr, an
internal variable in System V mailx, although it has not been
documented in the SVID.
The indentprefix variable, the retain and unalias commands, and
the ~F and ~M command escapes were adopted from 4.3 BSD Mail.
The version command was not included because no sufficiently
general specification of the version information could be devised
that would still be useful to a portable user. This command name
should be used by suppliers who wish to provide version
information about the mailx command.
The ``implementation-specific (unspecified) system start-up
file'' historically has been named /etc/mailx.rc, but this
specific name and location are not required.
The intent of the wording for the next command is that if any
command has already displayed the current message it should
display a following message, but, otherwise, it should display
the current message. Consider the command sequence:
next 3
delete 3
next
where the autoprint option was not set. The normative text
specifies that the second next command should display a message
following the third message, because even though the current
message has not been displayed since it was set by the delete
command, it has been displayed since the current message was
anything other than message number 3. This does not always match
historical practice in some implementations, where the command
file address followed by next (or the default command) would skip
the message for which the user had searched.
