Provided by: nmh_1.3-1_i386 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.