Provided by: nmh_1.8-3_amd64 
NAME
mhlist - list information about nmh MIME messages
SYNOPSIS
mhlist [-help] [-version] [+folder] [msgs] [-file file] [-part number] ... [-type content] ... [-prefer
content] ... [-noprefer] [-headers | -noheaders] [-realsize | -norealsize] [-changecur |
-nochangecur] [-verbose | -noverbose] [-disposition | -nodisposition]
DESCRIPTION
The mhlist command allows you to list information (a table of contents, essentially) about the various
parts of a collection of MIME (multi-media) messages.
mhlist manipulates MIME messages as specified in RFC 2045 to RFC 2049 (See mhbuild(1)).
The -headers switch indicates that a one-line banner should be displayed above the listing (the default).
The -realsize switch tells mhlist to evaluate the “native” (decoded) format of each content prior to
listing. This provides an accurate count at the expense of a small delay. In either case, sizes will be
expressed using SI prefix abbreviations (K/M/G/T), which are based on factors of 1000.
If the -verbose switch is present, then the listing will show any “extra” information that is present in
the message, such as comments in the “Content-Type” header.
If the -disposition switch is present, then the listing will show any relevant information from the
“Content-Disposition” header.
The option -file file directs mhlist to use the specified file as the source message, rather than a
message from a folder. If you specify this file as “-”, then mhlist will accept the source message on
the standard input. Note that the file, or input from standard input should be a validly formatted
message, just like any other nmh message. It should not be in mail drop format (to convert a file in
mail drop format to a folder of nmh messages, see inc(1)).
By default, mhlist will list information about the entire message (all of its parts). By using the
-part, -type, and -prefer switches, you may limit and reorder the set of parts to be listed, based on
part number and/or content type.
A part specification consists of a series of numbers separated by dots. For example, in a multipart
content containing three parts, these would be named as 1, 2, and 3, respectively. If part 2 was also a
multipart content containing two parts, these would be named as 2.1 and 2.2, respectively. Note that the
-part switch is effective only for messages containing a multipart content. If a message has some other
kind of content, or if the part is itself another multipart content, the -part switch will not prevent
the content from being acted upon.
The -type switch can also be used to restrict (or, when used in conjunction with -part, to further
restrict) the selection of parts according to content type. One or more -type switches part will only
select the first match from a multipart/alternative, even if there is more than one subpart that matches
(one of) the given content type(s).
Using either -part or -type switches alone will cause either to select the part(s) they match. Using
them together will select only the part(s) matched by both (sets of) switches. In other words, the
result is the intersection, and not the union, of their separate match results.
A content specification consists of a content type and a subtype. The initial list of “standard” content
types and subtypes can be found in RFC 2046.
A list of commonly used contents is briefly reproduced here:
Type Subtypes
---- --------
text plain, enriched
multipart mixed, alternative, digest, parallel
message rfc822, external-body
application octet-stream, postscript
image jpeg, gif, png
audio basic
video mpeg
A legal MIME message must contain a subtype specification.
To specify a content, regardless of its subtype, just use the name of the content, e.g., “audio”. To
specify a specific subtype, separate the two with a slash, e.g., “audio/basic”. Note that regardless of
the values given to the -type switch, a multipart content (of any subtype listed above) is always acted
upon. Further note that if the -type switch is used, and it is desirable to act on a message/external-
body content, then the -type switch must be used twice: once for message/external-body and once for the
content externally referenced.
By default, the parts of a multipart/alternative part are listed in the reverse order of their placement
in the message. The listing, therefore, is in decreasing order of preference, as defined in RFC 2046.
The -prefer switch can be used (one or more times, in order of ascending preference) to let MH know which
content types from a multipart/alternative MIME part are preferred by the user, in order to override the
default preference order. Thus, when viewed by mhlist, the ordering of multipart/alternative parts will
appear to change when invoked with or without various -prefer switches. The -noprefer switch will cancel
any previous -prefer switches. The -prefer and -noprefer switches are functionally most important for
mhshow, but are also implemented in mhlist and mhstore to make common part numbering possible across all
three programs.
FILES
$HOME/.mh_profile The user profile
PROFILE COMPONENTS
Path: To determine the user's nmh directory
Current-Folder: To find the default current folder
SEE ALSO
mhbuild(1), mhshow(1), mhstore(1)
DEFAULTS
`+folder' defaults to the current folder
`msgs' defaults to cur
`-headers'
`-realsize'
`-changecur'
`-noverbose'
`-nodisposition'
CONTEXT
If a folder is given, it will become the current folder. The last message selected will become the
current message, unless the -nochangecur option is specified.
nmh-1.8 2015-02-06 MHLIST(1mh)