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] [-changecur |
            -nochangecur] [-verbose | -noverbose] [-disposition | -nodisposition] [-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 to 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.

       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)).

       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.

       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 1521.

   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)

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  become  the
       current message, unless the -nochangecur option is specified.

nmh-1.6                                         February 12, 2013                                    MHLIST(1mh)