MAILX(1P)

📦 version 2017a, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, nixpkgs unstable, opensuse-leap 16.0

💖 PROLOG 💖

okay bestie, quick heads-up: this page is part of the POSIX Programmer's Manual, and it's the mailx(1P) page — yes, the manual name is folded in right here at the top, no boring header line for us. 💅 The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details on Linux behavior), or the interface may not be implemented on Linux. no cap

🎀 NAME 🎀

mailx — process messages

✨ SYNOPSIS ✨

💌 Send Mode

mailx [-s subject] address...

📬 Receive Mode

mailx -e

mailx [-HiNn] [-F] [-u user]

mailx -f [-HiNn] [-F] [file]

🌸 DESCRIPTION 🌸

The mailx utility provides a message sending and receiving facility. It has two major modes, selected by the options used: Send Mode and Receive Mode. It's giving duality, honestly. 🦋

On systems that do not support the User Portability Utilities option, an application using mailx shall have the ability to send messages in an unspecified manner (Send Mode). Unless the first character of one or more lines is <tilde> ('~'), all characters in the input message shall appear in the delivered message, but additional characters may be inserted in the message before it is retrieved.

On systems supporting the User Portability Utilities option, mail-receiving capabilities and other interactive features, Receive Mode, described below, also shall be enabled.

📤 Send Mode

Send Mode can be used by applications or users to send messages from the text in standard input. Simple as that, bestie.

📥 Receive Mode

Receive Mode is more oriented towards interactive users. Mail can be read and sent in this interactive mode.

When reading mail, mailx provides commands to facilitate saving, deleting, and responding to messages. When sending mail, mailx allows editing, reviewing, and other modification of the message as it is entered. Main character energy fr fr. 👑

Incoming mail shall be stored in one or more unspecified locations for each user, collectively called the system mailbox for that user. When mailx is invoked in Receive Mode, the system mailbox shall be the default place to find new mail. As messages are read, they shall be marked to be moved to a secondary file for storage, unless specific action is taken. This secondary file is called the mbox and is normally located in the directory referred to by the HOME environment variable (see MBOX in the ENVIRONMENT VARIABLES section for a description of this file). Messages shall remain in this file until explicitly removed. When the -f option is used to read mail messages from secondary files, messages shall be retained in those files unless specifically removed. All three of these locations—system mailbox, mbox, and secondary file—are referred to in this section as simply “mailboxes”, unless more specific identification is required.

💅 OPTIONS 💅

The mailx utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines.

The following options shall be supported. (Only the -s subject option shall be required on all systems. The other options are required only on systems supporting the User Portability Utilities option.)

-e — Test for the presence of mail in the system mailbox. The mailx utility shall write nothing and exit with a successful return code if there is mail to read. 👀
-f — Read messages from the file named by the file operand instead of the system mailbox. (See also folder.) If no file operand is specified, read messages from mbox instead of the system mailbox.
-F — Record the message in a file named after the first recipient. The name is the login-name portion of the address found first on the To: line in the mail header. Overrides the record variable, if set (see Internal Variables in mailx).
-H — Write a header summary only.
-i — Ignore interrupts. (See also ignore.)
-n — Do not initialize from the system default start-up file. See the EXTENDED DESCRIPTION section.
-N — Do not write an initial header summary.
-s subject — Set the Subject header field to subject. All characters in the subject string shall appear in the delivered message. The results are unspecified if subject is longer than {LINE_MAX} - 10 bytes or contains a <newline>.
-u user — Read the system mailbox of the login name user. This shall only be successful if the invoking user has appropriate privileges to read the system mailbox of that user. 🔐

🫶 OPERANDS 🫶

The following operands shall be supported:

address — Addressee of message. When -n is specified and no user start-up files are accessed (see the EXTENDED DESCRIPTION section), the user or application shall ensure this is an address to pass to the mail delivery system. Any system or user start-up files may enable aliases (see alias under Commands in mailx) that may modify the form of address before it is passed to the mail delivery system.
file — A pathname of a file to be read instead of the system mailbox when -f is specified. The meaning of the file option-argument shall be affected by the contents of the folder internal variable; see Internal Variables in mailx.

🌈 STDIN 🌈

When mailx is invoked in Send Mode (the first synopsis line), standard input shall be the message to be delivered to the specified addresses. When in Receive Mode, user commands shall be accepted from stdin. If the User Portability Utilities option is not supported, standard input lines beginning with a <tilde> ('~') character produce unspecified results. 😭

If the User Portability Utilities option is supported, then in both Send and Receive Modes, standard input lines beginning with the escape character (usually <tilde> ('~')) shall affect processing as described in Command Escapes in mailx.

🦋 INPUT FILES 🦋

When mailx is used as described by this volume of POSIX.1‐2017, the file option-argument (see the -f option) and the mbox shall be text files containing mail messages, formatted as described in the OUTPUT FILES section. The nature of the system mailbox is unspecified; it need not be a file. ✨

🌈 ENVIRONMENT VARIABLES 🌈

okay so bestie, this is the part where the shell whispers little vibe-notes to mailx before it even starts working 💌 some of the stuff in here is only provided on implementations that support the User Portability Utilities option (the text will literally tell you as we go), and it is not further shaded for that option. periodt.

The following environment variables shall affect the execution of mailx:

DEAD — this one sets the pathname of the file where partial messages get saved when there's an interrupt or a delivery error 😭 the default shall be dead.letter, sitting in the directory named by the HOME variable. heads up though: the behavior of mailx when saving partial messages is unspecified if the User Portability Utilities option is not supported and DEAD is not defined with the value /dev/null.
EDITOR — tells mailx the name of the utility to invoke when the edit command is used (see Commands in mailx) or when the ~e command escape is used (see Command Escapes in mailx) ✍️ the default editor is unspecified. On XSI-conformant systems it is ed. The effects of this variable are unspecified if the User Portability Utilities option is not supported.
HOME — determines the pathname of the user's home directory 🏠 iconic, essential, the blueprint.
LANG — provides a default value for the internationalization variables that are unset or null 🌍 (See the Base Definitions volume of POSIX.1‐2017, Section 8.2, Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.)
LC_ALL — if set to a non-empty string value, it overrides the values of all the other internationalization variables 👑 like, it said "I'm the main character here."
LC_CTYPE — determines the locale for interpreting sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files) and for the handling of case-insensitive address and header-field comparisons 🔤
LC_TIME — this variable may determine the format and contents of the date and time strings written by mailx ⏰ this volume of POSIX.1‐2017 specifies the effects of this variable only for systems supporting the User Portability Utilities option.
LC_MESSAGES — determines the locale that should be used to affect the format and contents of diagnostic messages written to standard error and informative messages written to standard output 💬
LISTER — determines a string representing the command for writing the contents of the folder directory to standard output when the folders command is given (see folders in Commands in mailx) 📂 any string acceptable as a command_string operand to the sh -c command shall be valid. If this variable is null or not set, the output command shall be ls. The effects of this variable are unspecified if the User Portability Utilities option is not supported.
MAILRC — determines the pathname of the user start-up file 📜 the default shall be .mailrc in the directory referred to by the HOME environment variable. The behavior of mailx is unspecified if the User Portability Utilities option is not supported and MAILRC is not defined with the value /dev/null.
MBOX — determines a pathname of the file to save messages from the system mailbox that have been read 📥 the exit command shall override this function, as shall saving the message explicitly in another file. The default shall be mbox in the directory named by the HOME variable. The effects of this variable are unspecified if the User Portability Utilities option is not supported.
NLSPATH — determines the location of message catalogs for the processing of LC_MESSAGES 🗺️
PAGER — determines a string representing an output filtering or pagination command for writing the output to the terminal 📖 any string acceptable as a command_string operand to the sh -c command shall be valid. When standard output is a terminal device, the message output shall be piped through the command if the mailx internal variable crt is set to a value less the number of lines in the message; see Internal Variables in mailx. If the PAGER variable is null or not set, the paginator shall be either more or another paginator utility documented in the system documentation. The effects of this variable are unspecified if the User Portability Utilities option is not supported.
SHELL — determines the name of a preferred command interpreter 🐚 the default shall be sh. The effects of this variable are unspecified if the User Portability Utilities option is not supported.
TERM — if the internal variable screen is not specified, this determines the name of the terminal type to indicate in an unspecified manner the number of lines in a screenful of headers 🖥️ if TERM is not set or is set to null, an unspecified default terminal type shall be used and the value of a screenful is unspecified. The effects of this variable are unspecified if the User Portability Utilities option is not supported.
TZ — this variable may determine the timezone used to calculate date and time strings written by mailx 🕰️ if TZ is unset or null, an unspecified default timezone shall be used.
VISUAL — determines a pathname of a utility to invoke when the visual command is used (see Commands in mailx) or the ~v command-escape is used (see Command Escapes in mailx) 👀 if this variable is null or not set, the full-screen editor shall be vi. The effects of this variable are unspecified if the User Portability Utilities option is not supported.

💀 ASYNCHRONOUS EVENTS 💀

When mailx is in Send Mode and standard input is not a terminal, it shall take the standard action for all signals.

In Receive Mode, or in Send Mode when standard input is a terminal, if a SIGINT signal is received:

If in command mode, the current command, if there is one, shall be aborted, and a command-mode prompt shall be written.
If in input mode:
- a. If ignore is set, mailx shall write "@\n", discard the current input line, and continue processing, bypassing the message-abort mechanism described in item 2b. 🚫
- b. If the interrupt was received while sending mail, either when in Receive Mode or in Send Mode, a message shall be written, and another subsequent interrupt, with no other intervening characters typed, shall be required to abort the mail message 😤 if in Receive Mode and another interrupt is received, a command-mode prompt shall be written. If in Send Mode and another interrupt is received, mailx shall terminate with a non-zero status.

In both cases listed in item b, if the message is not empty:

i. If save is enabled and the file named by DEAD can be created, the message shall be written to the file named by DEAD. If the file exists, the message shall be written to replace the contents of the file. 💾
ii. If save is not enabled, or the file named by DEAD cannot be created, the message shall not be saved. 😭

The mailx utility shall take the standard action for all other signals.

🌸 STDOUT 🌸

In command and input modes, all output, including prompts and messages, shall be written to standard output ✨ every last drop.

🙈 STDERR 🙈

The standard error shall be used only for diagnostic messages. that's it, that's the whole job.

📁 OUTPUT FILES 📁

Various mailx commands and command escapes can create or add to files, including the mbox, the dead-letter file, and secondary mailboxes 📬 when mailx is used as described in this volume of POSIX.1‐2017, these files shall be text files, formatted as follows:

line beginning with From<space>
[one or more header-lines; see Commands in mailx]
empty line
[zero or more body lines
empty line]
[line beginning with From<space>...]

where each message begins with the From <space> line shown, preceded by the beginning of the file or an empty line. (The From <space> line is considered to be part of the message header, but not one of the header-lines referred to in Commands in mailx; thus, it shall not be affected by the discard, ignore, or retain commands.) The formats of the remainder of the From <space> line and any additional header lines are unspecified, except that none shall be empty. The format of a message body line is also unspecified, except that no line following an empty line shall start with From <space>; mailx shall modify any such user-entered message body lines (following an empty line and beginning with From <space>) by adding one or more characters to precede the 'F'; it may add these characters to From <space> lines that are not preceded by an empty line. 🛠️

When a message from the system mailbox or entered by the user is not a text file, it is implementation-defined how such a message is stored in files written by mailx.

👑 EXTENDED DESCRIPTION 👑

The functionality in the entire EXTENDED DESCRIPTION section shall be provided on implementations supporting the User Portability Utilities option. The functionality described in this section shall be provided on implementations that support the User Portability Utilities option (and the rest of this section is not further shaded for this option). 💅

The mailx utility need not support for all character encodings in all circumstances. For example, inter-system mail may be restricted to 7-bit data by the underlying network, 8-bit data need not be portable to non-internationalized systems, and so on. Under these circumstances, it is recommended that only characters defined in the ISO/IEC 646:1991 standard International Reference Version (equivalent to ASCII) 7-bit range of characters be used 🌈 no cap, keep it ASCII-clean when the network is being picky.

When mailx gets invoked using one of the Receive Mode synopsis forms, it shall write a page of header-summary lines (unless -N was specified or there are no messages, see below), and then it drops a prompt letting you know mailx can accept regular commands (peep Commands in mailx for that). This whole moment? It's called command mode 💅. That page of header-summary lines shall contain the first new message if there are new messages, or the first unread message if there are unread messages, or the first message. And when mailx is invoked using the Send Mode synopsis and standard input is a terminal, if no subject got specified on the command line and the asksub variable is set, a prompt for the subject shall be written. Right here, mailx shall be in input mode. This input mode shall also be entered when you're using one of the Receive Mode synopsis forms and a reply or new message gets composed using the reply, Reply, followup, Followup, or mail commands, and standard input is a terminal. When the message is typed and the end of the message is encountered, the message shall be passed to the mail delivery software. You can enter commands by beginning a line with the escape character (by default, <tilde> ('~')) followed by a single command letter and optional arguments. See Commands in mailx for a summary of these commands. It is unspecified what effect these commands will have if standard input is not a terminal when a message is entered using either the Send Mode synopsis, or the Read Mode commands reply, Reply, followup, Followup, or mail.

Note: for notational convenience, this section uses the default escape character, <tilde>, in all references and examples. 🎀

At any time, the behavior of mailx shall be governed by a set of environmental and internal variables. These are flags and valued parameters that can be set and cleared via the mailx set and unset commands.

Regular commands are of the form:

[command] [msglist] [argument ...]

If no command is specified in command mode, next shall be assumed. In input mode, commands shall be recognized by the escape character, and lines not treated as commands shall be taken as input for the message.

In command mode, each message shall be assigned a sequential number, starting with 1.

All messages have a state that shall affect how they are displayed in the header summary and how they are retained or deleted upon termination of mailx. There is at any time the notion of a current message, which shall be marked by a '>' at the beginning of a line in the header summary. When mailx is invoked using one of the Receive Mode synopsis forms, the current message shall be the first new message, if there is a new message, or the first unread message if there is an unread message, or the first message if there are any messages, or unspecified if there are no messages in the mailbox. Each command that takes an optional list of messages (msglist) or an optional single message (message) on which to operate shall leave the current message set to the highest-numbered message of the messages specified, unless the command deletes messages, in which case the current message shall be set to the first undeleted message (that is, a message not in the deleted state) after the highest-numbered message deleted by the command, if one exists, or the first undeleted message before the highest-numbered message deleted by the command, if one exists, or to an unspecified value if there are no remaining undeleted messages. All messages shall be in one of the following states:

new — The message is present in the system mailbox and has not been viewed by the user or moved to any other state. Messages in state new when mailx quits shall be retained in the system mailbox.
unread — The message has been present in the system mailbox for more than one invocation of mailx and has not been viewed by the user or moved to any other state. Messages in state unread when mailx quits shall be retained in the system mailbox.
read — The message has been processed by one of the following commands: ~f, ~m, ~F, ~M, copy, mbox, next, pipe, print, Print, top, type, Type, undelete. The delete, dp, and dt commands may also cause the next message to be marked as read, depending on the value of the autoprint variable. Messages that are in the system mailbox and in state read when mailx quits shall be saved in the mbox, unless the internal variable hold was set. Messages that are in the mbox or in a secondary mailbox and in state read when mailx quits shall be retained in their current location.
deleted — The message has been processed by one of the following commands: delete, dp, dt. Messages in state deleted when mailx quits shall be deleted. Deleted messages shall be ignored until mailx quits or changes mailboxes or they are specified to the undelete command; for example, the message specification /string shall only search the subject lines of messages that have not yet been deleted, unless the command operating on the list of messages is undelete. No deleted message or deleted message header shall be displayed by any mailx command other than undelete. 💀
preserved — The message has been processed by a preserve command. When mailx quits, the message shall be retained in its current location.
saved — The message has been processed by one of the following commands: save or write. If the current mailbox is the system mailbox, and the internal variable keepsave is set, messages in the state saved shall be saved to the file designated by the MBOX variable (see the ENVIRONMENT VARIABLES section). If the current mailbox is the system mailbox, messages in the state saved shall be deleted from the current mailbox, when the quit or file command is used to exit the current mailbox.

The header-summary line for each message shall indicate the state of the message.

Many commands take an optional list of messages (msglist) on which to operate, which defaults to the current message. A msglist is a list of message specifications separated by <blank> characters, which can include:

n — Message number n.
+ — The next undeleted message, or the next deleted message for the undelete command.
- — The next previous undeleted message, or the next previous deleted message for the undelete command.
. — The current message.
^ — The first undeleted message, or the first deleted message for the undelete command.
$ — The last message.
* — All messages.
n‐m — An inclusive range of message numbers.
address — All messages from address; any address as shown in a header summary shall be matchable in this form.
/string — All messages with string in the subject line (case ignored).
:c — All messages of type c, where c shall be one of:
- d — Deleted messages.
- n — New messages.
- o — Old messages (any not in state read or new).
- r — Read messages.
- u — Unread messages.

Other commands take an optional message (message) on which to operate, which defaults to the current message. All of the forms allowed for msglist are also allowed for message, but if more than one message is specified, only the first shall be operated on.

Other arguments are usually arbitrary strings whose usage depends on the command involved.

🌸 Start-Up in mailx 🌸

At start-up time, mailx shall take the following steps in sequence:

Establish all variables at their stated default values.
Process command line options, overriding corresponding default values.
Import any of the DEAD, EDITOR, MBOX, LISTER, PAGER, SHELL, or VISUAL variables that are present in the environment, overriding the corresponding default values.
Read mailx commands from an unspecified system start-up file, unless the -n option is given, to initialize any internal mailx variables and aliases.
Process the user start-up file of mailx commands named in the user MAILRC variable.

Most regular mailx commands are valid inside start-up files, the most common use being to set up initial display options and alias lists. The following commands shall be invalid in a start-up file: !, edit, hold, mail, preserve, reply, Reply, shell, visual, Copy, followup, and Followup. Any errors in a start-up file shall either cause mailx to terminate with a diagnostic message and a non-zero status or to continue after writing a diagnostic message, ignoring the remainder of the lines in the file.

A blank line in a start-up file shall be ignored. ✨

🧚 Internal Variables in mailx 🧚

The following variables are internal mailx variables. Each internal variable can be set via the mailx set command at any time. The unset and set noname commands can be used to erase variables.

In the following list, variables shown as:

variable

represent Boolean values. Variables shown as:

variable=value

shall be assigned string or numeric values. For string values, the rules in Commands in mailx concerning filenames and quoting shall also apply.

The defaults specified here may be changed by the unspecified system start-up file unless the user specifies the -n option.

allnet — All network names whose login name components match shall be treated as identical. This shall cause the msglist message specifications to behave similarly. The default shall be noallnet. See also the alternates command and the metoo variable.
append — Append messages to the end of the mbox file upon termination instead of placing them at the beginning. The default shall be noappend. This variable shall not affect the save command when saving to mbox.
ask, asksub — Prompt for a subject line on outgoing mail if one is not specified on the command line with the -s option. The ask and asksub forms are synonyms; the system shall refer to asksub and noasksub in its messages, but shall accept ask and noask as user input to mean asksub and noasksub. It shall not be possible to set both ask and noasksub, or noask and asksub. The default shall be asksub, but no prompting shall be done if standard input is not a terminal.
askbcc — Prompt for the blind copy list. The default shall be noaskbcc.
askcc — Prompt for the copy list. The default shall be noaskcc.
autoprint — turns on automatic writing of messages after the delete and undelete commands. Default is noautoprint. ✨
bang — turns on the special-case treatment of <exclamation-mark> characters ('!') in escape command lines; peep the escape command and Command Escapes in mailx for the lore. Default is nobang, which disables the expansion of '!' in the command argument to the ~! command and the ~<!command escape. 💥
cmd=command — sets the default command that the pipe command invokes. Default is nocmd.
crt=number — pipes messages that have more than number lines through whatever command the PAGER variable is set to. Default is nocrt. If you set it to null, the value used is implementation-defined (iykyk, your mileage may vary 🙈).
debug — turns on verbose diagnostics for debugging. Messages are not delivered. Default is nodebug.
dot — when dot is set, a <period> all alone on a line during message input from a terminal also means end-of-file (on top of the normal end-of-file). Default is nodot. If ignoreeof is set (see below 👇), then a setting of nodot gets ignored and the <period> is the only way to terminate input mode.
escape=c — sets the command escape character to the character c. By default the command escape character is <tilde>. If escape is unset, <tilde> is used; if it's set to null, command escaping is fully disabled.
flipr — swaps the meanings of the R and r commands. Default is noflipr.
folder=directory — the default directory for saving mail files. User-specified filenames starting with a <plus-sign> ('+') get expanded by sticking this directory name in front of the filename to get the real pathname. If directory doesn't start with a <slash> ('/'), the contents of HOME get prefixed to it. Default is nofolder. If folder is unset or set to null, user-specified filenames starting with '+' refer to files in the current directory that begin with the literal '+' character. See also outfolder below. The folder value doesn't have to affect the processing of the files named in MBOX and DEAD. 📁
header — enables writing of the header summary when you enter mailx in Receive Mode. Default is header.
hold — preserves all messages that are read in the system mailbox instead of dropping them into the mbox save file. Default is nohold.
ignore — ignores interrupts while you're entering messages. Default is noignore.
ignoreeof — ignores normal end-of-file during message input. Input can only be terminated by entering a <period> ('.') on a line by itself or by the ~. command escape. Default is noignoreeof. See also dot above. 🫶
indentprefix=string — a string added as a prefix to every line that the ~m command escape inserts into the message. Defaults to one <tab>.
keep — when a system mailbox, secondary mailbox, or mbox is empty, truncates it to zero length instead of removing it. Default is nokeep.
keepsave — keeps the messages that have been saved out of the system mailbox into other files in the file designated by the MBOX variable, instead of deleting them. Default is nokeepsave.
metoo — suppresses the deletion of the user's login name from the recipient list when replying to a message or sending to a group. Default is nometoo.
onehop — when you respond to a message that was originally sent to several recipients, the other recipient addresses are normally forced to be relative to the originating author's machine for the response. This flag disables alteration of the recipients' addresses, which improves efficiency in a network where all machines can send directly to all other machines (that is, one hop away). Default is noonehop.
outfolder — causes the files used to record outgoing messages to live in the directory specified by the folder variable, unless the pathname is absolute. Default is nooutfolder. See the record variable.
page — inserts a <form-feed> after each message sent through the pipe created by the pipe command. Default is nopage.
prompt=string — sets the command-mode prompt to string. If string is null or if noprompt is set, no prompting happens at all. By default it prompts with the string "? ".
quiet — refrains from writing the opening message and version when you enter mailx. Default is noquiet. 🤫
record=file — records all outgoing mail in the file with the pathname file. Default is norecord. See also outfolder above.
save — enables saving of messages in the dead-letter file on interrupt or delivery error. See the DEAD variable for where the dead-letter file lives. Default is save.
screen=number — sets the number of lines in a screenful of headers for the headers and z commands. If screen isn't specified, a value based on the terminal type identified by the TERM environment variable, the window size, the baud rate, or some combo of those gets used.
sendwait — waits for the background mailer to finish before returning. Default is nosendwait.
showto — when the sender of the message was the user invoking mailx, writes the info from the To: line instead of the From: line in the header summary. Default is noshowto.
sign=string — sets the variable inserted into the text of a message when the ~a command escape is given. Default is nosign. The character sequences '\t' and '\n' are recognized in the variable as <tab> and <newline> characters respectively. (See also ~i in Command Escapes in mailx.)
Sign=string — sets the variable inserted into the text of a message when the ~A command escape is given. Default is noSign. The character sequences '\t' and '\n' are recognized in the variable as <tab> and <newline> characters respectively.
toplines=number — sets the number of lines of the message to write with the top command. Default is 5.

🦋 Commands in mailx 🦋

These are the mailx commands you're getting, bestie. In the list below, header means lines from the message header, exactly like the OUTPUT FILES section shows them. Header-line means lines within the header that begin with one or more non-white-space characters, immediately followed by a <colon> and white space, and continuing until the next line that begins with a non-white-space character or an empty line. And Header-field means the portion of a header line prior to the first <colon> in that line. 🧚

For every command listed below, you can type it as the abbreviation (those characters in the Synopsis command word preceding the '['), the full command (all characters shown for the command word, minus the '[' and ']'), or any truncation of the full command down to the abbreviation. For example, the exit command (shown as ex[it] in the Synopsis) can be entered as ex, exi, or exit. Periodt. 💅

The arguments to commands can be quoted, using these methods:

An argument can be enclosed between paired double-quotes ("") or single-quotes (''); any white space, shell word expansion, or <backslash> characters inside the quotes get treated literally as part of the argument. A double-quote gets treated literally inside single-quotes and vice versa. These special properties of the <quotation-mark> characters only kick in when they're paired at the beginning and end of the argument.
A <backslash> outside of the enclosing quotes gets discarded, and the following character gets treated literally as part of the argument.
An unquoted <backslash> at the end of a command line gets discarded, and the next line continues the command.

Filenames, where expected, get put through these transformations, in sequence:

If the filename begins with an unquoted <plus-sign>, and the folder variable is defined (see the folder variable), the <plus-sign> gets replaced by the value of the folder variable followed by a <slash>. If the folder variable is unset or set to null, the filename stays unchanged.
Shell word expansions get applied to the filename (see Section 2.6, Word Expansions). If more than a single pathname comes out of this expansion and the command is expecting one file, the effects are unspecified. 💀

💖 Declare Aliases 💖

Synopsis:

a[lias] [alias [address...]]
g[roup] [alias [address...]]

Adds the given addresses to the alias specified by alias. The names get substituted when alias is used as a recipient address that the user specified in an outgoing message — that is, other recipients addressed indirectly through the reply command do not get substituted this way. Mail address alias substitution only applies when the alias string is used as a full address; for example, when hlj is an alias, hlj@posix.com does not trigger the alias substitution. 🚫

If no arguments are given, it writes a listing of the current aliases to standard output. If only an alias argument is given, it writes a listing of the specified alias to standard output. Heads up: these listings don't have to reflect the same order of addresses that were entered. 🙃

🌈 Declare Alternatives 🌈

Synopsis:

alt[ernates] name...

(See also the metoo variable.) Declares a list of alternative names for the user's login. When responding to a message, these names get removed from the list of recipients for the response. The comparison of names is case-insensitive. With no arguments, alternates writes the current list of alternative names. 👑

🎀 Change Current Directory 🎀

Synopsis:

cd [directory]
ch[dir] [directory]

Changes directory. If directory isn't specified, the contents of HOME get used. 🏠

✨ Copy Messages ✨

Synopsis:

                     c[opy] [file]
                     c[opy] [msglist] file
                     C[opy] [msglist]

Copy the messages into the file named by the pathname file — and do not mark them as saved. Apart from that lil detail, it's literally the save command, same vibe, different bookkeeping. ✨

Capitalized C[opy]? That one tucks the specified messages into a file whose name is derived from the author of the message being saved, still without marking anything as saved. Otherwise it's the Save command's twin. 💅

Delete Messages 💀

Synopsis:

                     d[elete] [msglist]

Marks the messages for deletion from the mailbox. Ok but here's the tea — the actual deletions do not happen until mailx quits (that's the quit command, iykyk) or changes mailboxes (the folder command). So they're on the hit list, not gone yet. 🙈

If autoprint is set and there are still messages hanging around after the delete command, the current message gets written the way the print command describes it. Otherwise? You just get the mailx prompt. No cap.

Discard Header Fields 🚫

Synopsis:

                     di[scard] [header-field...]
                     ig[nore] [header-field...]

Suppress the specified header fields whenever messages get written out. Whatever header-fields you name get added to the list of suppressed ones. Classic ones to ignore are status and cc. The fields shall be included when the message is saved though, so nothing's really lost. The Print and Type commands override this whole thing. Comparing header fields is case-insensitive, bestie — STATUS and status are the same girl. 🌸

If you pass no arguments at all, it writes a list of the currently suppressed header fields to standard output; the listing doesn't have to reflect the same order the header fields were entered in. Order is not the moment. ✨

If both retain and discard commands are given, the discard commands shall be ignored. Pick a side, babe.

Delete Messages and Display 👀

Synopsis:

                     dp [msglist]
                     dt [msglist]

Delete the specified messages just like the delete command does — except the autoprint variable has no effect here, and the current message only gets written if it was set to a message after the last message deleted by the command. Otherwise you get an informational message to the effect that there are no further messages in the mailbox, followed by the mailx prompt. That's it, that's the message. 😭

Echo a String 📢

Synopsis:

                     ec[ho] string ...

Echo the given strings — literally equivalent to the shell echo utility. Simple, iconic, no notes.

Edit Messages 📝

Synopsis:

                     e[dit] [msglist]

Edit the given messages. They get placed in a temporary file, and the utility named by the EDITOR variable is invoked to edit each file in sequence. The default EDITOR is unspecified — so, uh, unspecified. Don't come for me. 🫶

The edit command does not modify the contents of those messages in the mailbox. Your edits are living their own separate life.

Exit 🚪

Synopsis:

                     ex[it]
                     x[it]

Exit from mailx without changing the mailbox. No messages shall be saved in the mbox. (See also quit — that one's a whole different energy.) 👑

Change Folder 📁

Synopsis:

                     fi[le] [file]
                     fold[er] [file]

Quit (yes, the quit command — see above) from the current file of messages and read in the file named by the pathname file. If you give no argument, the name and status of the current mailbox get written instead. Cute little status check. 💖

Several unquoted special characters get recognized when used as file names, with these substitutions:

% — The system mailbox for the invoking user.
%user — The system mailbox for user.
# — The previous file.
& — The current mbox.
+file — The named file in the folder directory. (See the folder variable.)

The default file shall be the current mailbox. Periodt.

Display List of Folders 🗂️

Synopsis:

                     folders

Write the names of the files in the directory set by the folder variable. The command specified by the LISTER environment variable gets used for this (peep the ENVIRONMENT VARIABLES section). Slay.

Follow Up Specified Messages ↩️

Synopsis:

                     fo[llowup] [message]
                     F[ollowup] [msglist]

Lowercase form: respond to a message, recording the response in a file whose name is derived from the author of the message. See also the save and copy commands and outfolder. 🌸

Capitalized form: respond to the first message in the msglist, sending the message to the author of each message in the msglist. The subject line gets taken from the first message, and the response gets recorded in a file whose name is derived from the author of the first message. See also the Save and Copy commands and outfolder. 💅

Both forms shall override the record variable, if it's set. Sorry to that variable.

Display Header Summary for Specified Messages 🎀

Synopsis:

                     f[rom] [msglist]

Write the header summary for the specified messages. That's the whole thing. Short and sweet. ✨

Display Header Summary 📜

Synopsis:

                     h[eaders] [message]

Write the page of headers that includes the message specified. If the message argument isn't specified, the current message shall not change. But if the message argument is specified, the current message becomes the message that appears at the top of the page of headers that includes the message you specified. The screen variable sets the number of headers per page. See also the z command. 😌

Help 🆘

Synopsis:

                     hel[p]
                     ?

Write a summary of commands. That's it. You're welcome, bestie.

Hold Messages 🤲

Synopsis:

                     ho[ld] [msglist]
                     pre[serve] [msglist]

Mark the messages in msglist to be retained in the mailbox when mailx terminates. This shall override any commands that might previously have marked those messages to be deleted. During the current invocation of mailx, only the delete, dp, or dt commands shall remove the preserve marking of a message. So basically: protected, unless you really mean it. 🛡️

Execute Commands Conditionally 🔀

Synopsis:

                     i[f] s|r
                     mail-commands
                     el[se]
                     mail-commands
                     en[dif]

Execute commands conditionally, where if s executes the following mail-commands, up to an else or endif, if the program is in Send Mode, and if r shall cause the mail-commands to be executed only in Receive Mode. Branching, but make it mail. 🌈

List Available Commands 📋

Synopsis:

                     l[ist]

Write a list of all commands available. No explanation shall be given. Just the names. Read the room. 💀

Mail a Message ✉️

Synopsis:

                     m[ail] address...

Mail a message to the specified addresses or aliases. Go off, main character. 👑

Direct Messages to mbox 📥

Synopsis:

                     mb[ox] [msglist]

Arrange for the given messages to end up in the mbox save file when mailx terminates normally. See MBOX. See also the exit and quit commands. 🫶

Process Next Specified Message ⏭️

Synopsis:

                     n[ext] [message]

If the current message hasn't been written (say, by the print command) since mailx started, or since any other message was the current message, behave as if the print command was entered. Otherwise, if there's an undeleted message after the current message, make it the current message and behave as if the print command was entered. Otherwise, an informational message to the effect that there are no further messages in the mailbox shall be written, followed by the mailx prompt. 😭

Should the current message location be the result of an immediately preceding hold, mbox, preserve, or touch command, next will act as if the current message has already been written. Sneaky, but that's the rule.

Pipe Message 🚰

Synopsis:

                     pi[pe] [[msglist] command]
                     | [[msglist] command]

Pipe the messages through the given command by invoking the command interpreter specified by SHELL with two arguments: -c and command. (See also sh -c.) The application shall ensure that the command is given as a single argument — quoting, described previously, can be used to accomplish this. If no arguments are given, the current message gets piped through the command specified by the value of the cmd variable. If the page variable is set, a <form-feed> shall be inserted after each message. Clean. ✨

Display Message with Headers 👑

Synopsis:

                     P[rint] [msglist]
                     T[ype] [msglist]

Write the specified messages, including all header lines, to standard output. This overrides the suppression of lines by the discard, ignore, and retain commands — yeah, it said what it said. If crt is set, messages longer than the number of lines specified by the crt variable shall be paged through the command specified by the PAGER environment variable. 📖

Display Message 💌

Synopsis:

                     p[rint] [msglist]
                     t[ype] [msglist]

Write the specified messages to standard output. If crt is set, the messages longer than the number of lines specified by the crt variable shall be paged through the command specified by the PAGER environment variable. Same energy, fewer headers. 🌸

Quit 🏁

Synopsis:

                     q[uit]
                     end-of-file

Terminate mailx, and while you're at it:

storing messages that were read in mbox (if the current mailbox is the system mailbox and unless hold is set)
deleting messages that have been explicitly saved (unless keepsave is set)
discarding messages that have been deleted
saving all remaining messages in the mailbox

The full send-off. Cleanup crew activated. 💅

Reply to a Message List 📨

Synopsis:

                     R[eply] [msglist]
                     R[espond] [msglist]

Mail a reply message to the sender of each message in the msglist. The subject line shall be formed by concatenating Re:<space> (unless it already begins with that string) and the subject from the first message. If record is set to a filename, the response shall be saved at the end of that file. 📎

Reply to a Message 💬

Synopsis:

                     r[eply] [message]
                     r[espond] [message]

Mail a reply message to all recipients included in the header of the message. The subject line shall be formed by concatenating Re:<space> (unless it already begins with that string) and the subject from the message. If record is set to a filename, the response shall be saved at the end of that file. 📎

Retain Header Fields 🛡️

Synopsis:

                     ret[ain] [header-field...]

Retain the specified header fields when writing messages. This command shall override all discard and ignore commands — yeah, it wins. Comparing header fields is case-insensitive. If no arguments are specified, write a list of the currently retained header fields to standard output; the listing need not reflect the same order of header fields that were entered. Order is a construct. 🦋

Save Messages 💾

Synopsis:

                     s[ave] [file]
                     s[ave] [msglist] file
                     S[ave] [msglist]

Save the specified messages into the file named by the pathname file, or into the mbox if you just… don't give a file argument at all, bestie. The file gets created if it doesn't already exist; if it does exist, the messages get appended to it. The message is then put in the state saved, and it'll behave exactly like the description of that saved state says when you exit the current mailbox with the quit or file command. 💾

In the capitalized form, it saves the specified messages into a file whose name is derived from the author of the first message. The name of that file shall be taken to be the author's name with all network addressing stripped off. See also the Copy, followup, and Followup commands and the outfolder variable. iykyk ✨

🎀 Set Variables 🎀

Synopsis:

se[t] [name[=[string]] ...] [name=number ...] [noname ...]

Define one or more variables called name. The variable can be given a null, string, or numeric value. Quoting and <backslash>-escapes can happen anywhere in string, as described previously, like the string portion of the argument was the whole entire argument, no cap. The forms name and name= shall be equivalent to name="" for variables that take string values. The set command with no arguments shall write a list of all defined variables and their values. The no name form shall be equivalent to unset name. 💅

🐚 Invoke a Shell 🐚

Synopsis:

sh[ell]

Invoke an interactive command interpreter (see also SHELL). It's giving "let me out into the world". 🫶

📏 Display Message Size 📏

Synopsis:

si[ze] [msglist]

Write the size in bytes of each of the specified messages. Simple. Iconic. ⭐

📂 Read mailx Commands From a File 📂

Synopsis:

so[urce] file

Read and execute commands from the file named by the pathname file, then return to command mode. Snack break, then back to business. 🍓

👀 Display Beginning of Messages 👀

Synopsis:

to[p] [msglist]

Write the top few lines of each of the specified messages. If the toplines variable is set, it's taken as the number of lines to write. The default shall be 5. Just a lil peek. 🙈

✋ Touch Messages ✋

Synopsis:

tou[ch] [msglist]

Touch the specified messages. If any message in msglist is not specifically deleted and not saved in a file, it shall be placed in the mbox upon normal termination. See exit and quit. Lowkey important, highkey underrated. 💜

💀 Delete Aliases 💀

Synopsis:

una[lias] [alias]...

Delete the specified alias names. If a specified alias does not exist, the results are unspecified. So like… be careful. 😭

🩹 Undelete Messages 🩹

Synopsis:

u[ndelete] [msglist]

Change the state of the specified messages from deleted to read. If autoprint is set, the last message of those restored shall be written. If msglist is not specified, the message shall be selected as follows:

If there are any deleted messages that follow the current message, the first of these shall be chosen.
Otherwise, the last deleted message that also precedes the current message shall be chosen.

Not me un-deleting things like nothing happened. 💅

🚫 Unset Variables 🚫

Synopsis:

uns[et] name...

Cause the specified variables to be erased. Gone. Poof. 🦋

🖥️ Edit Message with Full-Screen Editor 🖥️

Synopsis:

v[isual] [msglist]

Edit the given messages with a screen editor. Each message shall be placed in a temporary file, and the utility named by the VISUAL variable shall be invoked to edit each file in sequence. The default editor shall be vi.

Heads up bestie: the visual command does not modify the contents of those messages in the mailbox. 👑

✍️ Write Messages to a File ✍️

Synopsis:

w[rite] [msglist] file

Write the given messages to the file specified by the pathname file, minus the message header. Otherwise, it shall be equivalent to the save command. 🎀

📜 Scroll Header Display 📜

Synopsis:

z[+|-]

Scroll the header display forward (if '+' is specified or if no option is specified) or backward (if '-' is specified) one screenful. The number of headers written shall be set by the screen variable. Scrolling, scrolling, scrolling… 🌈

💥 Invoke Shell Command 💥

Synopsis:

!command

Invoke the command interpreter specified by SHELL with two arguments: -c and command. (See also sh -c.) If the bang variable is set, each unescaped occurrence of '!' in command shall be replaced with the command executed by the previous ! command or ~! command escape. Recursion?? In my mail client?? It's more likely than you think. 💀

🌸 Null Command 🌸

Synopsis:

# comment

This null command (comment) shall be ignored by mailx. A no-op. A vibe. Nothing more. ✨

🔢 Display Current Message Number 🔢

Synopsis:

Write the current message number. That's it. That's the whole command. Periodt. 👑

🧚 Command Escapes in mailx 🧚

The following commands can be entered only from input mode, by beginning a line with the escape character (by default, <tilde> ('~')). See the escape variable description for changing this special character. The format for the commands shall be:

<escape-character><command-char><separator>[<arguments>]

where the <separator> can be zero or more <blank> characters. (Zero! Yes really! 🫶)

In the following descriptions, the application shall ensure that the argument command (but not mailx-command) is a shell command string. Any string acceptable to the command interpreter specified by the SHELL variable when it's invoked as SHELL -c command_string shall be valid. The command can be presented as multiple arguments (that is, quoting is not required).

🚨 Warning bestie: command escapes that are listed with msglist or mailx-command arguments are invalid in Send Mode and produce unspecified results. Do not do this. I am begging. 😭

~! command — Invoke the command interpreter specified by SHELL with two arguments: -c and command; and then return to input mode. If the bang variable is set, each unescaped occurrence of '!' in command shall be replaced with the command executed by the previous ! command or ~! command escape. 💥
~. — Simulate end-of-file (terminate message input). Bye bestie! 👋
~: mailx-command, ~_ mailx-command — Perform the command-level request.
~? — Write a summary of command escapes. The help menu of the century. ⭐
~A — This shall be equivalent to ~i Sign. (Capital S, capital energy. 👑)
~a — This shall be equivalent to ~i sign.
~b name... — Add the names to the blind carbon copy (Bcc) list. 🤫
~c name... — Add the names to the carbon copy (Cc) list. 💌
~d — Read in the dead-letter file. See DEAD for a description of this file. 💀
~e — Invoke the editor, as specified by the EDITOR environment variable, on the partial message. ✏️
~f [msglist] — Forward the specified messages. The specified messages shall be inserted into the current message without alteration. This command escape also shall insert message headers into the message with field selection affected by the discard, ignore, and retain commands.
~F [msglist] — This shall be the equivalent of the ~f command escape, except that all headers shall be included in the message, regardless of previous discard, ignore, and retain commands. No filtering, no games. 🔥
~h — If standard input is a terminal, prompt for a Subject line and the To, Cc, and Bcc lists. Other implementation-defined headers may also be presented for editing. If the field is written with an initial value, it can be edited as if it had just been typed. ✨
~i string — Insert the value of the named variable, followed by a <newline>, into the text of the message. If the string is unset or null, the message shall not be changed.
~m [msglist] — Insert the specified messages into the message, prefixing non-empty lines with the string in the indentprefix variable. This command escape also shall insert message headers into the message, with field selection affected by the discard, ignore, and retain commands. 🌸
~M [msglist] — This shall be the equivalent of the ~m command escape, except that all headers shall be included in the message, regardless of previous discard, ignore, and retain commands.
~p — Write the message being entered. If the message is longer than crt lines (see Internal Variables in mailx), the output shall be paginated as described for the PAGER variable. 📄
~q — Quit (see the quit command) from input mode by simulating an interrupt. If the body of the message is not empty, the partial message shall be saved in the dead-letter file. See DEAD for a description of this file. 💀
~r file, ~< file, ~r !command, ~< !command — Read in the file specified by the pathname file. If the argument begins with an <exclamation-mark> ('!'), the rest of the string shall be taken as an arbitrary system command; the command interpreter specified by SHELL shall be invoked with two arguments: -c and command. The standard output of command shall be inserted into the message. 🫶
~s string — Set the subject line to string. 💅
~t name... — Add the given names to the To list. 💖
~v — Invoke the full-screen editor, as specified by the VISUAL environment variable, on the partial message. 🖥️
~w file — Write the partial message, without the header, onto the file named by the pathname file. The file shall be created, or the message shall be appended to it if the file exists.
~x — Exit as with ~q, except the message shall not be saved in the dead-letter file. 🦋
~| command — Pipe the body of the message through the given command by invoking the command interpreter specified by SHELL with two arguments: -c and command. If the command returns a successful exit status, the standard output of the command shall replace the message. Otherwise, the message shall remain unchanged. If the command fails, an error message giving the exit status shall be written. 🔥

🌟 EXIT STATUS 🌟

When the -e option is specified, the following exit values are returned:

0 — Mail was found. 💖
>0 — Mail was not found or an error occurred. 😭

Otherwise, the following exit values are returned:

0 — Successful completion; note that this status implies that all messages were sent, but it gives no assurances that any of them were actually delivered. (Read that again bestie. Sent ≠ delivered. 👑)
>0 — An error occurred. 💀

💀 CONSEQUENCES OF ERRORS 💀

okay bestie, listen up, this is the part where we talk about what happens when stuff goes wrong, and it depends entirely on what mode you're in, so let's go:

When you're in input mode (that's Receive Mode) or Send Mode:

if an error pops up while processing an input line that starts with a <tilde> character ('~') — peek at Command Escapes in mailx for the lore — then a diagnostic message shall be written to standard error, and yeah the message you're composing may be modified, but lowkey this condition shall not stop the message from being sent. it goes through. it's fine. 💅
but other errors? nope. those shall prevent the sending of the message. periodt.

When you're in command mode:

Default. that's it, that's the whole vibe.

The following sections are informative. (translation: they're the ✨ bonus lore ✨, not the rules-rules, but still absolutely worth your time 🫶)

🌈 APPLICATION USAGE 🌈

So, sending messages to remote systems? That requires communication paths to actually exist to those systems. These need not exist. Not a typo, not a drill, that's genuinely what it says. 💀

Input lines are limited to {LINE_MAX} bytes, but heads up — mailers between systems may impose more severe line-length restrictions, so it's giving chaos out there. This volume of POSIX.1‐2017 does not place any restrictions on the length of messages handled by mailx, and for delivery of local messages the only limitations should be the normal problems of available disk space for the target mail file. But when you're sending messages to external machines, applications are advised to limit messages to less than 100000 bytes, because some mail gateways impose message-length restrictions. protect your peace and your payload size, bestie 🎀

The format of the system mailbox is intentionally unspecified. Not all systems implement system mailboxes as flat files — especially with the advent of multimedia mail messages. Some system mailboxes may be multiple files, others records in a database. The internal format of the messages themselves is specified with the historical format from Version 7, but only after the messages have been saved in some file other than the system mailbox. Why? So that many historical applications expecting text-file mailboxes are not broken. iconic backwards compatibility behaviour honestly 👑

Some new formats for messages can be expected in the future — probably including binary data, bit maps, and various multimedia objects. As described here, mailx is not prohibited from handling such messages, but it must store them as text files in secondary mailboxes (unless some extension, like a variable or command line option, is used to change the stored format). Its method of doing so is implementation-defined and might include translating the data into text file-compatible or readable form, or omitting certain portions of the message from the stored output. wild, but okay ✨

The discard and ignore commands are not inverses of the retain command. Let me say that again for the people in the back:

retain discards all header-fields except those explicitly retained.
discard keeps all header-fields except those explicitly discarded.

And if headers exist on the retained header list, discard and ignore commands are ignored. the way these three are NOT the same thing 😭

🦋 EXAMPLES 🦋

None. literally nothing. zero. a beautiful empty page. slay 🙈

👑 RATIONALE 👑

okay this is the big one, the director's commentary, the why behind everything. strap in 💖

The standard developers felt strongly that a method for applications to send messages to specific users was necessary. The obvious example? A batch utility, running non-interactively, that wishes to communicate errors or results to a user. However — and this is key — 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, because 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. no cap, they just didn't want to pick a side yet 🫶

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). collect them all like pokémon ⭐

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. so do it or don't, whatever, just know the vibes 💅

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, like by using different command names. so no, editing does not save back. it's giving window shopping 🌸

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>. That said, many historical mailers that a message may encounter on other systems are not able to handle lines that long. 😭

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. relatable honestly 💀

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. protect your message, protect your peace 🎀

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 ambiguity is intentional, bestie ✨

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 — like 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. fair point honestly 🦋

Options to specify addresses as cc (carbon copy) or bcc (blind carbon copy) were considered to be format details and were omitted. they just didn't make the cut 🙈

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. so zero is not a promise, it's a vibe 🔥

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 it 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. two names, one queen 👑

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. rip echo, you will not be missed 🕊️

The default prompt on the System V mailx is a <question-mark>, and on BSD Mail it's 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. chaos, but documented chaos 💅

The indentprefix variable, the retain and unalias commands, and the ~F and ~M command escapes were adopted from 4.3 BSD Mail. borrowed with love 🌸

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. so if you see version out in the wild, that's a vendor thing, not a POSIX thing ✨

The ``implementation-specific (unspecified) system start-up file'' historically has been named /etc/mailx.rc, but this specific name and location are not required. historical lore only 🫶

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. subtle, messy, very real 😭

⭐ FUTURE DIRECTIONS ⭐

None. nothing on the horizon. a peaceful, empty horizon. slay 💜

🔥 SEE ALSO 🔥

Chapter 2, Shell Command Language, ed, ls, more, vi
The Base Definitions volume of POSIX.1‐2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines

📜 COPYRIGHT 💖

okay bestie, legal era, let's get into it — and yes, we're keeping every single word, because copyright notices are the one thing you do not freestyle. 🫶

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. 💅

real talk: if this version and the original IEEE and The Open Group Standard ever disagree about <em>anything</em>, the original IEEE and The Open Group Standard is the referee document. like, it's the main character, this is just the group chat retelling. no cap. 👑

The original Standard can be obtained online at http://www.opengroup.org/unix/online.html — go get it from the source, bestie, it's giving official. ✨

🦋 typos & formatting oopsies 🎀

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. 😭 the glow-up from source file to man page is a whole journey and sometimes a butterfly loses a wing, yk?

To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html — snitch kindly, they wanna know. 🐛➡️📬

and that's a wrap on the whole page, bestie!! 🎀 this lil doc came to you courtesy of IEEE and The Open Group, dated 2017, and it lives under the name MAILX(1P) — go forth and send your mail, you absolute icon. 💖🦋✨👑

📦 where this page comes from

alpine 3.22: man-pages-posix 2017a-r0 · custom
alpine 3.23: man-pages-posix 2017a-r0 · custom
alpine 3.24: man-pages-posix 2017a-r0 · custom
arch rolling: man-pages 6.19-1
arch rolling: man-pages 6.20-1 · BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
nixpkgs unstable: man-pages-posix 2017a
opensuse-leap 16.0: man-pages-posix 2017a-160000.4.1 · SUSE-IEEE
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-18: a language model's rewrite of the original, under its terms