mhlist



MHLIST(1)                                                            MHLIST(1)




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]
            [-verbose] [-noverbose] [-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.

       The `-headers' switch indicates that a one-line banner should  be  dis-
       played 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  mes-
       sages 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  mes-
       sage/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)
       RFC-2045:
          Multipurpose Internet Mail Extensions (MIME) Part One:
          Format of Internet Message Bodies,
       RFC-2046:
          Multipurpose Internet Mail Extensions (MIME) Part Two:
          Media Types,
       RFC-2047:
          Multipurpose Internet Mail Extensions (MIME) Part Three:
          Message Header Extensions for Non-ASCII Text,
       RFC-2048:
          Multipurpose Internet Mail Extensions (MIME) Part Four:
          Registration Procedures,
       RFC-2049:
          Multipurpose Internet Mail Extensions (MIME) Part Five:
          Conformance Criteria and Examples.


DEFAULTS

       `+folder' defaults to the current folder
       `msgs' defaults to cur
       `-nocheck'
       `-headers'
       `-realsize'
       `-rcache ask'
       `-wcache ask'
       `-noverbose'


CONTEXT

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



[nmh-1.0.4]                         MH.6.8                           MHLIST(1)

Man(1) output converted with man2html