# mhlist(1) - man - phpMan

[MHLIST(1mh)](https://www.chedong.com/phpMan.php/man/MHLIST/1mh/markdown)                                                                              [MHLIST(1mh)](https://www.chedong.com/phpMan.php/man/MHLIST/1mh/markdown)



## NAME
       mhlist - list information about nmh MIME messages

## SYNOPSIS
       **mhlist** [**-help**] [**-version**] [_+folder_] [_msgs_] [**-file** _file_] [**-part** _number_] ...  [**-type** _content_]
            ...  [**-prefer** _content_] ...  [**-noprefer**] [**-headers** | **-noheaders**] [**-realsize** | **-noreal**‐‐
            **size**] [**-rcache** _policy_] [**-wcache** _policy_] [**-check** | **-nocheck**] [**-changecur** | **-nochangecur**]
            [**-verbose** | **-noverbose**] [**-disposition** | **-nodisposition**]

## DESCRIPTION
       The **mhlist** command allows you to list information (a table of  contents,  essentially)  about
       the various parts of a collection of MIME (multi-media) messages.

       **mhlist** manipulates MIME messages as specified in RFC 2045 to RFC 2049 (See [_mhbuild_(1)](https://www.chedong.com/phpMan.php/man/mhbuild/1/markdown)).

       The  **-headers**  switch  indicates that a one-line banner should be displayed above the listing
       (the default).

       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.  In ei‐
       ther case, sizes will be expressed using SI prefix abbreviations (K/M/G/T), which  are  based
       on factors of 1000.

       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)](https://www.chedong.com/phpMan.php/man/inc/1/markdown)).

       By default, **mhlist** will list information about the entire message (all of its parts).  By us‐
       ing  the **-part**, **-type**, and **-prefer** switches, you may limit and reorder the set of parts to be
       listed, based on part number and/or content type.

       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 only for messages containing a
       multipart content.  If a message has some other kind of content, or if the part is itself an‐
       other multipart content, the **-part** switch will not prevent the content from being acted upon.

       The  **-type**  switch  can also be used to restrict (or, when used in conjunction with **-part**, to
       further restrict) the selection of parts according  to  content  type.   One  or  more  **-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).

       Using either **-part** or **-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.

       A content specification consists of a content type and a subtype.  The initial list of “stan‐
       dard” 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., “au‐
       dio”.   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.

       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  prefer‐
       ence, as defined in RFC 2046.  The **-prefer** switch can be used (one or more times, in order of
       ascending 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 **mhlist**, the ordering of multipart/alternative parts will appear to change when
       invoked  with or without various **-prefer** switches.  The **-noprefer** switch will cancel any pre‐
       vious **-prefer** switches.  The **-prefer** and **-noprefer** switches are functionally  most  important
       for **mhshow**, but are also implemented in **mhlist** and **mhstore** to make common part numbering pos‐
       sible across all three programs.

### 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)](https://www.chedong.com/phpMan.php/man/mhbuild/1/markdown), [_mhshow_(1)](https://www.chedong.com/phpMan.php/man/mhshow/1/markdown), [_mhstore_(1)](https://www.chedong.com/phpMan.php/man/mhstore/1/markdown)

## 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  be‐
       come the current message, unless the **-nochangecur** option is specified.



nmh-1.7.1                                    2015-02-06                                  [MHLIST(1mh)](https://www.chedong.com/phpMan.php/man/MHLIST/1mh/markdown)
