NAME¶
mhlist - list information about MIME messages
SYNOPSIS¶
mhlist [+folder] [msgs] [-file
file] [-part number] ... [-type content]
... [-headers | -noheaders] [-realsize |
-norealsize] [-rcache policy] [-wcache
policy] [-check | -nocheck] [-changecur |
-nochangecur] [-verbose | -noverbose]
[-disposition | -nodisposition] [-version]
[-help]
DESCRIPTION¶
The
mhlist command allows you to list information (essentially a table of
contents) about the various parts of a collection of MIME (multi-media)
messages.
mhlist manipulates MIME (multi-media 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
-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.
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 and
-type switches, you may limit
the scope of this command to particular subparts (of a multipart content)
and/or particular content types.
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 for only 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.
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, partial, 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.
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 1521.
Checking the Contents¶
The
-check switch tells
mhlist to check each content for an
integrity checksum. If a content has such a checksum (specified as a
Content-MD5 header field), then
mhlist will attempt to verify the
integrity of the content.
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
`-nocheck'
`-headers'
`-realsize'
`-rcache ask'
`-wcache ask'
`-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.