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  (essen­
        tially  a  table of contents) about the various parts of a
        collection of MIME (multi-media) messages.
 
        mhlist manipulates MIME (multi-media messages)  as  speci­
        fied in RFC-2045 thru RFC-2049.
 
        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 list­
        ing.  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  mes­
        sage, such as comments in the Content-Type header.
 
        The  option  `-file file' directs mhlist to use the speci­
        fied 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 mes­
        sages, 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 sepa­
        rated by dots.  For example, in a multipart  content  con­
        taining  three parts, these would be named as 1, 2, and 3,
        respectively.  If part 2 was also a multipart content con­
        taining  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 spe­
        cific 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)
        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 message selected will become the current message.
 
 
 
 [nmh-1.0.4]                   MH.6.8                    MHLIST(1)

---