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.