+.TH MHLIST %manext1% "February 6, 2015" "%nmhversion%"
.\"
.\" %nmhwarning%
.\"
-.TH MHLIST %manext1% "%nmhdate%" MH.6.8 [%nmhversion%]
.SH NAME
mhlist \- list information about MIME messages
.SH SYNOPSIS
.HP 5
.na
.B mhlist
+.RB [ \-help ]
+.RB [ \-version ]
.RI [ +folder ]
.RI [ msgs ]
.RB [ \-file
.RB [ \-type
.IR content ]
\&...
+.RB [ \-prefer
+.IR content ]
+\&...
.RB [ \-headers " | " \-noheaders ]
.RB [ \-realsize " | " \-norealsize ]
.RB [ \-rcache
.RB [ \-wcache
.IR policy ]
.RB [ \-check " | " \-nocheck ]
-.RB [ \-version ]
-.RB [ \-help ]
+.RB [ \-changecur " | " \-nochangecur ]
+.RB [ \-verbose " | " \-noverbose ]
+.RB [ \-disposition " | " \-nodisposition ]
.ad
.SH DESCRIPTION
The
.PP
.B mhlist
manipulates MIME (multi-media messages) as specified
-in RFC\-2045 thru RFC\-2049 (See
-.BR mhbuild (1)).
+in RFC 2045 to RFC 2049 (See
+.IR mhbuild (1)).
.PP
The
.B \-headers
to evaluate the
\*(lqnative\*(rq (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.
.PP
If the
.B \-verbose
any \*(lqextra\*(rq information that is present in the message,
such as comments in the \*(lqContent-Type\*(rq header.
.PP
+If the
+.B \-disposition
+switch is present, then the listing will show any relevant information from
+the \*(lqContent-Disposition\*(rq header.
+.PP
The option
.B \-file
.I file
a folder of
.B nmh
messages, see
-.BR inc (1)).
+.IR inc (1)).
.PP
By default,
.B mhlist
will list information about the entire
message (all of its parts). By using the
-.B \-part
+.BR \-part ,
+.BR \-type ,
and
-.B \-type
-switches, you may limit the scope of this command to particular
-subparts (of a multipart content) and/or particular content types.
-.PP
-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
+.B \-prefer
+switches, you may limit and reorder the set of parts to be listed,
+based on part number and/or content type.
+.PP
+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
.B \-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
+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
.B \-part
switch will not prevent the content from being acted upon.
.PP
+The
+.B \-type
+switch can also be used to restrict (or, when used in conjunction with
+.BR \-part ,
+to further restrict) the selection of parts according to content type.
+One or more
+.B \-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).
+.PP
+Using either
+.B \-part
+or
+.B -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.
+.PP
A content specification consists of a content type and a subtype.
The initial list of \*(lqstandard\*(rq content types and subtypes can
-be found in RFC\-2046.
+be found in RFC 2046.
.PP
A list of commonly used contents is briefly reproduced here:
.PP
switch must
be used twice: once for message/external-body and once for the content
externally referenced.
+.PP
+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
+.B \-prefer
+switch can be used (one or more times, in order of descending
+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
+.BR mhlist ,
+the ordering of multipart/alternative parts will appear to change when
+invoked with or without various
+.B \-prefer
+switches.
+The
+.B \-prefer
+switch is functionally most important for
+.IR mhshow ,
+but is also implemented in
+.B mhlist
+and
+.B mhstore
+to make common part numbering possible across all three programs.
.SS "Checking the Contents"
The
.B \-check
.B mhlist
will attempt to verify the
integrity of the content.
-
.SH FILES
.fc ^ ~
.nf
-.ta \w'%etcdir%/ExtraBigFileName 'u
+.ta \w'%nmhetcdir%/ExtraBigFileName 'u
^$HOME/\&.mh\(ruprofile~^The user profile
.fi
-
.SH "PROFILE COMPONENTS"
.fc ^ ~
.nf
^Path:~^To determine the user's nmh directory
^Current\-Folder:~^To find the default current folder
.fi
-
.SH "SEE ALSO"
-mhbuild(1), mhshow(1), mhstore(1), sendfiles(1)
-
+.IR mhbuild (1),
+.IR mhshow (1),
+.IR mhstore (1)
.SH DEFAULTS
.nf
.RB ` +folder "' defaults to the current folder"
.RB ` \-nocheck '
.RB ` \-headers '
.RB ` \-realsize '
-.RB ` \-rcache ask '
-.RB ` \-wcache ask '
+.RB ` \-rcache\ ask '
+.RB ` \-wcache\ ask '
+.RB ` \-changecur '
.RB ` \-noverbose '
+.RB ` \-nodisposition '
.fi
-
.SH CONTEXT
If a folder is given, it will become the current folder. The last
-message selected will become the current message.
+message selected will become the current message, unless the
+.B \-nochangecur
+option is specified.
projects / nmh / blobdiff