1MHLIST(1)                   General Commands Manual                  MHLIST(1)
2
3
4

NAME

6       mhlist - list information about nmh MIME messages
7

SYNOPSIS

9       mhlist [-help] [-version] [+folder] [msgs] [-file file] [-part number]
10            ...  [-type content] ...  [-prefer content] ...  [-noprefer]
11            [-headers | -noheaders] [-realsize | -norealsize] [-rcache policy]
12            [-wcache policy] [-check | -nocheck] [-changecur | -nochangecur]
13            [-verbose | -noverbose] [-disposition | -nodisposition]
14

DESCRIPTION

16       The mhlist command allows you to list information (a table of contents,
17       essentially) about the various parts of a collection  of  MIME  (multi-
18       media) messages.
19
20       mhlist  manipulates  MIME messages as specified in RFC 2045 to RFC 2049
21       (See mhbuild(1)).
22
23       The -headers switch indicates that a one-line  banner  should  be  dis‐
24       played above the listing (the default).
25
26       The  -realsize  switch  tells mhlist to evaluate the “native” (decoded)
27       format of each content prior to listing.   This  provides  an  accurate
28       count  at  the expense of a small delay.  In either case, sizes will be
29       expressed using SI prefix abbreviations (K/M/G/T), which are  based  on
30       factors of 1000.
31
32       If  the  -verbose  switch  is  present,  then the listing will show any
33       “extra” information that is present in the message, such as comments in
34       the “Content-Type” header.
35
36       If  the  -disposition switch is present, then the listing will show any
37       relevant information from the “Content-Disposition” header.
38
39       The option -file file directs mhlist to use the specified file  as  the
40       source  message,  rather  than a message from a folder.  If you specify
41       this file as “-”, then mhlist will accept the  source  message  on  the
42       standard  input.   Note  that  the  file,  or input from standard input
43       should be a validly formatted message, just like any other nmh message.
44       It  should  not  be in mail drop format (to convert a file in mail drop
45       format to a folder of nmh messages, see inc(1)).
46
47       By default, mhlist will list information about the entire message  (all
48       of  its  parts).   By using the -part, -type, and -prefer switches, you
49       may limit and reorder the set of parts to be listed, based on part num‐
50       ber and/or content type.
51
52       A part specification consists of a series of numbers separated by dots.
53       For example, in a multipart content containing three parts, these would
54       be  named as 1, 2, and 3, respectively.  If part 2 was also a multipart
55       content containing two parts, these would be  named  as  2.1  and  2.2,
56       respectively.   Note  that  the -part switch is effective only for mes‐
57       sages containing a multipart content.  If a message has some other kind
58       of  content,  or  if  the part is itself another multipart content, the
59       -part switch will not prevent the content from being acted upon.
60
61       The -type switch can also be used to restrict (or, when  used  in  con‐
62       junction  with  -part,  to  further  restrict)  the  selection of parts
63       according to content type.  One or more -type switches part  will  only
64       select  the  first match from a multipart/alternative, even if there is
65       more than one subpart that matches (one of) the given content type(s).
66
67       Using either -part or -type switches alone will cause either to  select
68       the  part(s)  they  match.   Using  them  together will select only the
69       part(s) matched by both (sets of) switches.  In other words, the result
70       is  the  intersection,  and  not  the  union,  of  their separate match
71       results.
72
73       A content specification consists of a content type and a subtype.   The
74       initial  list  of “standard” content types and subtypes can be found in
75       RFC 2046.
76
77       A list of commonly used contents is briefly reproduced here:
78
79            Type         Subtypes
80            ----         --------
81            text         plain, enriched
82            multipart    mixed, alternative, digest, parallel
83            message      rfc822, partial, external-body
84            application  octet-stream, postscript
85            image        jpeg, gif, png
86            audio        basic
87            video        mpeg
88
89       A legal MIME message must contain a subtype specification.
90
91       To specify a content, regardless of its subtype, just use the  name  of
92       the  content,  e.g.,  “audio”.  To specify a specific subtype, separate
93       the two with a slash, e.g., “audio/basic”.  Note that regardless of the
94       values  given  to the -type switch, a multipart content (of any subtype
95       listed above) is always acted upon.  Further note  that  if  the  -type
96       switch  is  used, and it is desirable to act on a message/external-body
97       content, then the -type switch  must  be  used  twice:  once  for  mes‐
98       sage/external-body and once for the content externally referenced.
99
100       By default, the parts of a multipart/alternative part are listed in the
101       reverse order of their placement in the message.  The  listing,  there‐
102       fore,  is  in  decreasing  order of preference, as defined in RFC 2046.
103       The -prefer switch can be used (one or more times, in order of  ascend‐
104       ing  preference)  to  let  MH  know  which  content types from a multi‐
105       part/alternative MIME part are preferred by the user, in order to over‐
106       ride  the  default  preference order.  Thus, when viewed by mhlist, the
107       ordering of multipart/alternative parts  will  appear  to  change  when
108       invoked with or without various -prefer switches.  The -noprefer switch
109       will cancel any previous -prefer switches.  The -prefer  and  -noprefer
110       switches  are  functionally  most  important  for  mhshow, but are also
111       implemented in mhlist and mhstore to make common part numbering  possi‐
112       ble across all three programs.
113
114   Checking the Contents
115       The  -check  switch tells mhlist to check each content for an integrity
116       checksum.  If a content has such a checksum (specified as a Content-MD5
117       header  field), then mhlist will attempt to verify the integrity of the
118       content.
119

FILES

121       $HOME/.mh_profile          The user profile
122

PROFILE COMPONENTS

124       Path:                To determine the user's nmh directory
125       Current-Folder:      To find the default current folder
126

SEE ALSO

128       mhbuild(1), mhshow(1), mhstore(1)
129

DEFAULTS

131       `+folder' defaults to the current folder
132       `msgs' defaults to cur
133       `-nocheck'
134       `-headers'
135       `-realsize'
136       `-rcache ask'
137       `-wcache ask'
138       `-changecur'
139       `-noverbose'
140       `-nodisposition'
141

CONTEXT

143       If a folder is given, it will become the current folder.  The last mes‐
144       sage  selected will become the current message, unless the -nochangecur
145       option is specified.
146
147
148
149nmh-1.7.1                         2015-02-06                         MHLIST(1)
Impressum