Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
MHLIST(1)		    General Commands Manual		     MHLIST(1)

       mhlist -	list information about MIME messages

       mhlist [+folder]	[msgs] [-file file] [-part number] ...	[-type con-
	    tent] ...  [-headers | -noheaders] [-realsize | -norealsize]
	    [-rcache policy] [-wcache policy] [-check |	-nocheck] [-changecur
	    | -nochangecur] [-verbose |	-noverbose] [-disposition | -nodispo-
	    sition] [-version] [-help]

       The  mhlist command allows you to list information (essentially a table
       of contents) about the various parts of a collection of MIME (multi-me-
       dia) 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  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 "ex-
       tra" 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  con-
       tent) 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,  re-
       spectively.   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/ex-
       ternal-body and once for	the content externally referenced.

       The parts of a multipart/alternative part are listed in the reverse or-
       der of their placement in the message.  The listing therefore is	in de-
       creasing	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

       $HOME/.mh_profile		    The	user profile

       Path:		    To determine the user's nmh	directory
       Current-Folder:	    To find the	default	current	folder

       mhbuild(1), mhshow(1), mhstore(1)

       `+folder' defaults to the current folder
       `msgs' defaults to cur
       `-rcache	ask'
       `-wcache	ask'

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

nmh-1.6			       February	12, 2013		     MHLIST(1)


Want to link to this manual page? Use this URL:

home | help