]> diplodocus.org Git - nmh/commitdiff
man pages -- clarify what -part and -type do when used together
authorPaul Fox <pgf@foxharp.boston.ma.us>
Fri, 6 Feb 2015 16:32:44 +0000 (11:32 -0500)
committerPaul Fox <pgf@foxharp.boston.ma.us>
Sun, 8 Feb 2015 22:01:58 +0000 (17:01 -0500)
man/mhlist.man
man/mhshow.man
man/mhstore.man

index 093b7a8cb06218e7319951869c53aa00c207179e..ee70811dea6fadc84f9dc6a9186afea5f3fdf93b 100644 (file)
@@ -1,4 +1,4 @@
-.TH MHLIST %manext1% "August 20, 2014" "%nmhversion%"
+.TH MHLIST %manext1% "February 6, 2015" "%nmhversion%"
 .\"
 .\" %nmhwarning%
 .\"
@@ -98,24 +98,46 @@ By default,
 .B mhlist
 will list information about the entire
 message (all of its parts).  By using the
-.B \-part
+.BR \-part ,
+.BR \-type ,
 and
-.B \-type
-switches, you may limit the scope of this command to particular
-subparts (of a multipart content) and/or particular content types.
-.PP
-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
+.B \-prefer
+switches, you may limit and reorder the set of parts to be listed,
+based on part number and/or content type.
+.PP
+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
 .B \-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
+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
 .B \-part
 switch will not prevent the content from being acted upon.
 .PP
+The
+.B \-type
+switch can also be used to restrict (or, when used in conjunction with
+.BR \-part ,
+to further restrict) the selection of parts according to content type.
+One or more
+.B \-type
+switches part will only select the first match
+from a multipart/alternative, even if there is more than one
+subpart that matches (one of) the given content type(s).
+.PP
+Using either
+.B \-part
+or
+.B -type
+switches alone will cause either to select
+the part(s) they match.  Using them together will select only
+the part(s) matched by both (sets of) switches.  In other
+words, the result is the intersection, and not the union, of their
+separate match results.
+.PP
 A content specification consists of a content type and a subtype.
 The initial list of \*(lqstandard\*(rq content types and subtypes can
 be found in RFC 2046.
@@ -177,7 +199,7 @@ but is also implemented in
 .B mhlist
 and
 .B mhstore
-to make common part number ordering possible across all three programs.
+to make common part numbering possible across all three programs.
 .SS "Checking the Contents"
 The
 .B \-check
index 67516be56c2260032044644fc59466209dbc6438..0d34d22f99650fe7a960975fad8e4c4f6eb8bba9 100644 (file)
@@ -1,4 +1,4 @@
-.TH MHSHOW %manext1% "April 9, 2014" "%nmhversion%"
+.TH MHSHOW %manext1% "February 6, 2015" "%nmhversion%"
 .\"
 .\" %nmhwarning%
 .\"
@@ -59,14 +59,13 @@ and
 .B \-noinlineonly
 switches.
 In addition, by using the
-.B \-part
+.BR \-part ,
+.BR \-type ,
 and
-.B \-type
-switches, you may
-further limit the scope of
-.B mhshow
-to particular subparts (of a
-multipart content) and/or particular content types.  The inclusion of any
+.B \-prefer
+switches, you may limit and reorder the set of parts to be displayed,
+based on part number and/or content type.
+The inclusion of any
 .B \-part
 or
 .B \-type
@@ -140,6 +139,16 @@ switches part will only select the first match
 from a multipart/alternative, even if there is more than one
 subpart that matches (one of) the given content type(s).
 .PP
+Using either
+.B \-part
+or
+.B -type
+switches alone will cause either to select
+the part(s) they match.  Using them together will select only
+the part(s) matched by both (sets of) switches.  In other
+words, the result is the intersection, and not the union, of their
+separate match results.
+.PP
 A content specification consists of a content type and a subtype.
 The initial list of \*(lqstandard\*(rq content types and subtypes can
 be found in RFC 2046.
index 2484d69ec526a3f6a99f1a71eae8ceb04a50c12e..fb0f57dd45a7ea2266c2e8e41b3b4bde7d3cd1a6 100644 (file)
@@ -1,4 +1,4 @@
-.TH MHSTORE %manext1% "March 2, 2014" "%nmhversion%"
+.TH MHSTORE %manext1% "February 6, 2015" "%nmhversion%"
 .\"
 .\" %nmhwarning%
 .\"
@@ -51,13 +51,12 @@ By default,
 will store all the parts of each message.
 Each part will be store in a separate file.  The header fields of
 the message are not stored.  By using the
-.B \-part
+.BR \-part ,
+.BR \-type ,
 and
-.B \-type
-switches, you may limit the scope of
-.B mhstore
-to particular
-subparts (of a multipart content) and/or particular content types.
+.B \-prefer
+switches, you may limit and reorder the set of parts to be stored,
+based on part number and/or content type.
 .PP
 The
 .B \-file
@@ -83,21 +82,40 @@ messages, see
 .PP
 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
+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
 .B \-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
+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
 .B \-part
-switch will not prevent
-the content from being acted upon.
+switch will not prevent the content from being acted upon.
+.PP
+The
+.B \-type
+switch can also be used to restrict (or, when used in conjunction with
+.BR \-part ,
+to further restrict) the selection of parts according to content type.
+One or more
+.B \-type
+switches part will only select the first match
+from a multipart/alternative, even if there is more than one
+subpart that matches (one of) the given content type(s).
+.PP
+Using either
+.B \-part
+or
+.B -type
+switches alone will cause either to select
+the part(s) they match.  Using them together will select only
+the part(s) matched by both (sets of) switches.  In other
+words, the result is the intersection, and not the union, of their
+separate match results.
 .PP
 A content specification consists of a content type and a subtype.
-The initial list of \*(lqstandard\*(rq content types and subtypes
-can be found in RFC 2046.
+The initial list of \*(lqstandard\*(rq content types and subtypes can
+be found in RFC 2046.
 .PP
 A list of commonly used contents is briefly reproduced here:
 .PP
@@ -145,7 +163,7 @@ but is also implemented in
 .B mhlist
 and
 .B mhstore
-to make common part number ordering possible across all three programs.
+to make common part numbering possible across all three programs.
 See
 .IR mhlist (1)
 and