Provided by: nmh_1.3-1build1_amd64 bug

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] [-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 thru 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.

       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.

   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), sendfiles(1)

DEFAULTS

       `+folder' defaults to the current folder
       `msgs' defaults to cur
       `-nocheck'
       `-headers'
       `-realsize'
       `-rcacheask'
       `-wcacheask'
       `-noverbose'

CONTEXT

       If  a  folder is given, it will become the current folder.  The last message selected will
       become the current message.