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] [-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
thru 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.
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.
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), sendfiles(1)
DEFAULTS
‘+folder’ defaults to the current folder
‘msgs’ defaults to cur
‘-nocheck’
‘-headers’
‘-realsize’
‘-rcacheask’
‘-wcacheask’
‘-noverbose’
CONTEXT
If a folder is given, it will become the current folder. The last
message selected will become the current message.