1MHLIST(1)                    [nmh-1.2-20070115cvs]                   MHLIST(1)
2
3
4

NAME

6       mhlist - list information about MIME messages
7

SYNOPSIS

9       mhlist [+folder] [msgs] [-file file] [-part number] ...  [-type con‐
10            tent] ...  [-headers | -noheaders] [-realsize | -norealsize]
11            [-rcache policy] [-wcache policy] [-check | -nocheck] [-version]
12            [-help]
13

DESCRIPTION

15       The mhlist command allows you to list information (essentially a  table
16       of  contents)  about  the various parts of a collection of MIME (multi-
17       media) messages.
18
19       mhlist manipulates MIME (multi-media messages) as specified in RFC-2045
20       thru RFC-2049 (See mhbuild(1)).
21
22       The  -headers  switch  indicates  that a one-line banner should be dis‐
23       played above the listing.
24
25       The -realsize switch tells mhlist to evaluate  the  “native”  (decoded)
26       format  of  each  content  prior to listing.  This provides an accurate
27       count at the expense of a small delay.
28
29       If the -verbose switch is present,  then  the  listing  will  show  any
30       “extra” information that is present in the message, such as comments in
31       the “Content-Type” header.
32
33       The option -file file directs mhlist to use the specified file  as  the
34       source  message,  rather  than a message from a folder.  If you specify
35       this file as “-”, then mhlist will accept the  source  message  on  the
36       standard  input.   Note  that  the  file,  or input from standard input
37       should be a validly formatted message, just like any other nmh message.
38       It  should  NOT  be in mail drop format (to convert a file in mail drop
39       format to a folder of nmh messages, see inc(1)).
40
41       By default, mhlist will list information about the entire message  (all
42       of  its  parts).   By using the -part and -type switches, you may limit
43       the scope of this command to particular subparts (of a  multipart  con‐
44       tent) and/or particular content types.
45
46       A part specification consists of a series of numbers separated by dots.
47       For example, in a multipart content containing three parts, these would
48       be  named as 1, 2, and 3, respectively.  If part 2 was also a multipart
49       content containing two parts, these would be  named  as  2.1  and  2.2,
50       respectively.   Note  that  the -part switch is effective for only mes‐
51       sages containing a multipart content.  If a message has some other kind
52       of  content,  or  if  the part is itself another multipart content, the
53       -part switch will not prevent the content from being acted upon.
54
55       A content specification consists of a content type and a subtype.   The
56       initial  list  of “standard” content types and subtypes can be found in
57       RFC-2046.
58
59       A list of commonly used contents is briefly reproduced here:
60
61            Type         Subtypes
62            ----         --------
63            text         plain, enriched
64            multipart    mixed, alternative, digest, parallel
65            message      rfc822, partial, external-body
66            application  octet-stream, postscript
67            image        jpeg, gif, png
68            audio        basic
69            video        mpeg
70
71       A legal MIME message must contain a subtype specification.
72
73       To specify a content, regardless of its subtype, just use the  name  of
74       the  content,  e.g.,  “audio”.  To specify a specific subtype, separate
75       the two with a slash, e.g., “audio/basic”.  Note that regardless of the
76       values  given  to the -type switch, a multipart content (of any subtype
77       listed above) is always acted upon.  Further note  that  if  the  -type
78       switch  is  used, and it is desirable to act on a message/external-body
79       content, then the -type switch  must  be  used  twice:  once  for  mes‐
80       sage/external-body and once for the content externally referenced.
81
82   Checking the Contents
83       The  -check  switch tells mhlist to check each content for an integrity
84       checksum.  If a content has such a checksum (specified as a Content-MD5
85       header  field), then mhlist will attempt to verify the integrity of the
86       content.
87
88

FILES

90       $HOME/.mh_profile          The user profile
91
92

PROFILE COMPONENTS

94       Path:                To determine the user's nmh directory
95       Current-Folder:      To find the default current folder
96
97

SEE ALSO

99       mhbuild(1), mhshow(1), mhstore(1), sendfiles(1)
100
101

DEFAULTS

103       `+folder' defaults to the current folder
104       `msgs' defaults to cur
105       `-nocheck'
106       `-headers'
107       `-realsize'
108       `-rcacheask'
109       `-wcacheask'
110       `-noverbose'
111
112

CONTEXT

114       If a folder is given, it will become the current folder.  The last mes‐
115       sage selected will become the current message.
116
117
118
119MH.6.8                            1 Jul 2003                         MHLIST(1)
Impressum