]> diplodocus.org Git - nmh/blob - man/mhstore.man
Remove unused NCWD and NPWD #defines.
[nmh] / man / mhstore.man
1 .TH MHSTORE %manext1% "October 7, 2016" "%nmhversion%"
2 .\"
3 .\" %nmhwarning%
4 .\"
5 .SH NAME
6 mhstore \- store contents of MIME messages into files
7 .SH SYNOPSIS
8 .HP 5
9 .na
10 .B mhstore
11 .RB [ \-help ]
12 .RB [ \-version ]
13 .RI [ +folder ]
14 .RI [ msgs ]
15 .RB [ \-file
16 .IR file ]
17 .RB [ \-outfile
18 .IR outfile ]
19 .RB [ \-part
20 .IR number ]
21 \&...
22 .RB [ \-type
23 .IR content ]
24 \&...
25 .RB [ \-prefer
26 .IR content ]
27 \&...
28 .RB [ \-auto " | " \-noauto ]
29 .RB [ \-clobber
30 .IR always " | " auto " | " suffix " | " ask " | " never ]
31 .RB [ \-rcache
32 .IR policy ]
33 .RB [ \-wcache
34 .IR policy ]
35 .RB [ \-check " | " \-nocheck ]
36 .RB [ \-verbose " | " \-noverbose ]
37 .ad
38 .SH DESCRIPTION
39 The
40 .B mhstore
41 command allows you to store the contents of a
42 collection of MIME (multi-media) messages into files or other
43 messages.
44 .PP
45 .B mhstore
46 manipulates multi-media messages as specified in
47 RFC 2045 to RFC 2049.
48 .PP
49 By default,
50 .B mhstore
51 will store all the parts of each message.
52 Each part will be store in a separate file. The header fields of
53 the message are not stored. By using the
54 .BR \-part ,
55 .BR \-type ,
56 and
57 .B \-prefer
58 switches, you may limit and reorder the set of parts to be stored,
59 based on part number and/or content type.
60 .PP
61 The
62 .B \-file
63 .I file
64 switch directs
65 .B mhstore
66 to use the specified
67 file as the source message, rather than a message from a folder.
68 If you specify this file as \*(lq-\*(rq, then
69 .B mhstore
70 will
71 accept the source message on the standard input. Note that the
72 file, or input from standard input should be a validly formatted
73 message, just like any other
74 .B nmh
75 message. It should
76 .B NOT
77 be in mail drop format (to convert a file in mail drop format to
78 a folder of
79 .B nmh
80 messages, see
81 .IR inc (1)).
82 .PP
83 A part specification consists of a series of numbers separated by
84 dots. For example, in a multipart content containing three parts,
85 these would be named as 1, 2, and 3, respectively. If part 2 was also
86 a multipart content containing two parts, these would be named as 2.1
87 and 2.2, respectively. Note that the
88 .B \-part
89 switch is effective for only messages containing a multipart content.
90 If a message has some other kind of content, or if the part is itself
91 another multipart content, the
92 .B \-part
93 switch will not prevent the content from being acted upon.
94 .PP
95 The
96 .B \-type
97 switch can also be used to restrict (or, when used in conjunction with
98 .BR \-part ,
99 to further restrict) the selection of parts according to content type.
100 One or more
101 .B \-type
102 switches part will only select the first match
103 from a multipart/alternative, even if there is more than one
104 subpart that matches (one of) the given content type(s).
105 .PP
106 Using either
107 .B \-part
108 or
109 .B -type
110 switches alone will cause either to select
111 the part(s) they match. Using them together will select only
112 the part(s) matched by both (sets of) switches. In other
113 words, the result is the intersection, and not the union, of their
114 separate match results.
115 .PP
116 A content specification consists of a content type and a subtype.
117 The initial list of \*(lqstandard\*(rq content types and subtypes can
118 be found in RFC 2046.
119 .PP
120 A list of commonly used contents is briefly reproduced here:
121 .PP
122 .RS 5
123 .nf
124 .ta \w'application 'u
125 Type Subtypes
126 ---- --------
127 text plain, enriched
128 multipart mixed, alternative, digest, parallel
129 message rfc822, partial, external-body
130 application octet-stream, postscript
131 image jpeg, gif, png
132 audio basic
133 video mpeg
134 .fi
135 .RE
136 .PP
137 A legal MIME message must contain a subtype specification.
138 .PP
139 To specify a content, regardless of its subtype, just use the name
140 of the content, e.g., \*(lqaudio\*(rq. To specify a specific
141 subtype, separate the two with a slash, e.g., \*(lqaudio/basic\*(rq.
142 Note that regardless of the values given to the
143 .B \-type
144 switch,
145 a multipart content (of any subtype listed above) is always acted
146 upon. Further note that if the
147 .B \-type
148 switch is used, and it is
149 desirable to act on a message/external-body content, then the
150 .B \-type
151 switch must be used twice: once for message/external-body
152 and once for the content externally referenced.
153 .PP
154 The
155 .B \-prefer
156 switch will alter the part ordering of multipart/alternative MIME sections
157 in order to override the sender-imposed default ordering.
158 The
159 .B \-prefer
160 switch is functionally most important for
161 .BR mhshow ,
162 but is also implemented in
163 .B mhlist
164 and
165 .B mhstore
166 to make common part numbering possible across all three programs.
167 See
168 .IR mhlist (1)
169 and
170 .IR mhshow (1)
171 for more information on
172 .BR \-prefer.
173 .SS "Checking the Contents"
174 The
175 .B \-check
176 switch tells
177 .B mhstore
178 to check each content for
179 an integrity checksum. If a content has such a checksum (specified
180 as a Content-MD5 header field), then
181 .B mhstore
182 will attempt to
183 verify the integrity of the content.
184 .SS "Storing the Contents"
185 .B mhstore
186 will store the contents of the named messages in
187 \*(lqnative\*(rq (decoded) format. Two things must be determined:
188 the directory to store the content, and the filenames. Files are
189 written in the directory given by the \*(lqnmh-storage\*(rq profile
190 entry, e.g.,
191 .PP
192 .RS 5
193 nmh-storage: /tmp
194 .RE
195 .PP
196 If this entry isn't present,
197 the current working directory is used.
198 .PP
199 If the
200 .B \-outfile
201 switch is given, its argument is used for the filename to store all
202 of the content, with \*(lq-\*(rq indicating standard output. If the
203 .B \-auto
204 switch is given, then
205 .B mhstore
206 will check if the message contains information indicating the filename
207 that should be used to store the content. This information should be
208 specified as the \*(lqfilename\*(rq attribute in the
209 \*(lqContent-Disposition\*(rq header or as the \*(lqname\*(rq
210 attribute in the \*(lqContent-Type\*(rq header for the content you are
211 storing. For security reasons, this filename will be ignored if it
212 begins with the character '/', '.', '|', or '!', or if it contains the
213 character '%'. We also recommend using a \*(lqnmh-storage\*(rq profile
214 entry or a
215 .B \-clobber
216 switch setting other than the default of \*(lqalways\*(rq to avoid
217 overwriting existing files.
218 .PP
219 If the
220 .B \-auto
221 switch is not given (or is being ignored for security
222 reasons) then
223 .B mhstore
224 will look in the user's profile for a
225 \*(lqformatting string\*(rq to determine how the different contents
226 should be stored. First,
227 .B mhstore
228 will look for an entry of
229 the form:
230 .PP
231 .RS 5
232 mhstore-store-<type>/<subtype>
233 .RE
234 .PP
235 to determine the formatting string. If this isn't found,
236 .B mhstore
237 will look for an entry of the form:
238 .PP
239 .RS 5
240 mhstore-store-<type>
241 .RE
242 .PP
243 to determine the formatting string.
244 .PP
245 If the formatting string starts with a \*(lq+\*(rq character, then
246 content is stored in the named folder. A formatting string consisting
247 solely of a \*(lq+\*(rq character is interpreted to be the current
248 folder.
249 .PP
250 If the formatting string consists solely of a \*(lq-\*(rq character,
251 then the content is sent to the standard output.
252 .PP
253 If the formatting string starts with a '|', then it represents
254 a command for
255 .B mhstore
256 to execute which should
257 ultimately store the content. The content will be passed to the
258 standard input of the command. Before the command is executed,
259 .B mhstore
260 will change to the appropriate directory, and any
261 escapes (given below) in the formatting string will be expanded.
262 The use of the \*(lq%a\*(rq sequence is not recommended because
263 the user has no control over the Content-Type parameter data.
264 .PP
265 Otherwise the formatting string will represent a pathname in which
266 to store the content. If the formatting string starts with a '/',
267 then the content will be stored in the full path given, else the
268 file name will be relative to the value of \*(lqnmh-storage\*(rq or
269 the current working directory. Any escapes (given below) will be
270 expanded, except for the a-escape. Note that if \*(lqnmh-storage\*(rq
271 is not an absolute path, it will be relative to the folder that
272 contains the message(s).
273 .PP
274 A command or pathname formatting string may contain the following
275 escapes. If the content isn't part of a multipart (of any subtype
276 listed above) content, the p-escapes are ignored.
277 .PP
278 .RS 5
279 .nf
280 .ta \w'%P 'u
281 %a Parameters from Content-Type (only valid with command)
282 %m Insert message number
283 %P Insert part number with leading dot
284 %p Insert part number without leading dot
285 %t Insert content type
286 %s Insert content subtype
287 %% Insert character %
288 .fi
289 .RE
290 .PP
291 If no formatting string is found,
292 .B mhstore
293 will check to see
294 if the content is application/octet-stream with parameter
295 \*(lqtype=tar\*(rq. If so,
296 .B mhstore
297 will choose an appropriate
298 filename. If the content is not application/octet-stream, then
299 .B mhstore
300 will check to see if the content is a message. If
301 so,
302 .B mhstore
303 will use the value \*(lq+\*(rq. As a last resort,
304 .B mhstore
305 will use the value \*(lq%m%P.%s\*(rq.
306 .PP
307 Example profile entries might be:
308 .PP
309 .RS 5
310 .nf
311 mhstore-store-text: %m%P.txt
312 mhstore-store-text: +inbox
313 mhstore-store-message/partial: +
314 mhstore-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
315 mhstore-store-image/jpeg: %m%P.jpg
316 mhstore-store-application/PostScript: %m%P.ps
317 .fi
318 .RE
319 .PP
320 The
321 .B \-verbose
322 switch directs
323 .B mhstore
324 to print out the names of files that it stores. For backward
325 compatibility, it is the default. The
326 .B \-noverbose
327 switch suppresses these printouts.
328 .PP
329 .SS "Overwriting Existing Files"
330 The
331 .B \-clobber
332 switch controls whether
333 .B mhstore
334 should overwrite existing files. The allowed values for this switch
335 and corresponding behavior when
336 .B mhstore
337 encounters an existing file are:
338 .PP
339 .RS 5
340 .nf
341 .ta \w'suffix 'u
342 always Overwrite existing file (default)
343 auto Create new file of form name-n.extension
344 suffix Create new file of form name.extension.n
345 ask Prompt the user to specify whether or not to overwrite
346 the existing file
347 never Do not overwrite existing file
348 .fi
349 .RE
350 .PP
351 With
352 .I auto
353 and
354 .IR suffix ,
355 .I n
356 is the lowest unused number, starting from one, in the same form. If
357 a filename does not have an extension (following a '.'), then
358 .I auto
359 and
360 .I suffix
361 create a new file of the form
362 .I name-n
363 and
364 .IR name.n ,
365 respectively. With
366 .I never
367 and
368 .IR ask ,
369 the exit status of
370 .B mhstore
371 will be the number of files that were requested but not stored.
372 .PP
373 With
374 .IR ask ,
375 if standard input is connected to a terminal,
376 the user is prompted to respond
377 .IR yes ,
378 .IR no ,
379 or
380 .I rename
381 to whether the file should be overwritten. The responses
382 can be abbreviated. If the user responds with
383 .IR rename ,
384 then
385 .B mhstore
386 prompts the user for the name of the new file to be created. If it is
387 a relative path name (does not begin with '/'), then it is relative to
388 the current directory. If it is an absolute or relative path to a
389 directory that does not exist, the user will be prompted whether to
390 create the directory. If standard input is not connected to a
391 terminal,
392 .I ask
393 behaves the same as
394 .IR always .
395 .SS "Reassembling Messages of Type message/partial"
396 .B mhstore
397 is also able to reassemble messages that have been
398 split into multiple messages of type \*(lqmessage/partial\*(rq.
399 .PP
400 When asked to store a content containing a partial message,
401 .B mhstore
402 will try to locate all of the portions and combine
403 them accordingly. The default is to store the combined parts as
404 a new message in the current folder, although this can be changed
405 using formatting strings as discussed above. Thus, if someone has
406 sent you a message in several parts (such as the output from
407 .BR sendfiles ),
408 you can easily reassemble them all into a single
409 message in the following fashion:
410 .PP
411 .RS 5
412 .nf
413 % mhlist 5-8
414 msg part type/subtype size description
415 5 message/partial 47K part 1 of 4
416 6 message/partial 47K part 2 of 4
417 7 message/partial 47K part 3 of 4
418 8 message/partial 18K part 4 of 4
419 % mhstore 5-8
420 reassembling partials 5,6,7,8 to folder inbox as message 9
421 % mhlist -verbose 9
422 msg part type/subtype size description
423 9 application/octet-stream 118K
424 (extract with uncompress | tar xvpf -)
425 type=tar
426 conversions=compress
427 .fi
428 .RE
429 .PP
430 This will store exactly one message, containing the sum of the
431 parts. It doesn't matter whether the partials are specified in
432 order, since
433 .B mhstore
434 will sort the partials, so that they
435 are combined in the correct order. But if
436 .B mhstore
437 can not
438 locate every partial necessary to reassemble the message, it will
439 not store anything.
440 .SS "External Access"
441 For contents of type message/external-body,
442 \fImhstore\fR supports these access-types:
443 .PP
444 .IP \(bu 4
445 afs
446 .IP \(bu 4
447 anon-ftp
448 .IP \(bu 4
449 ftp
450 .IP \(bu 4
451 local-file
452 .IP \(bu 4
453 mail-server
454 .IP \(bu 4
455 url
456 .PP
457 For the \*(lqanon-ftp\*(rq and \*(lqftp\*(rq access types,
458 .B mhstore
459 will look for the \*(lqnmh-access-ftp\*(rq
460 profile entry, e.g.,
461 .PP
462 .RS 5
463 nmh-access-ftp: myftp.sh
464 .RE
465 .PP
466 to determine the pathname of a program to perform the FTP retrieval.
467 This program is invoked with these arguments:
468 .PP
469 .RS 5
470 .nf
471 domain name of FTP-site
472 username
473 password
474 remote directory
475 remote filename
476 local filename
477 \*(lqascii\*(rq or \*(lqbinary\*(rq
478 .fi
479 .RE
480 .PP
481 The program should terminate with an exit status of zero if the
482 retrieval is successful, and a non-zero exit status otherwise.
483 .PP
484 For the \*(lqurl\*(rq access types,
485 .B mhstore
486 will look for the \*(lqnmh-access-url\*(rq profile entry, e.g.,
487 .PP
488 .RS 5
489 nmh-access-url: curl -L
490 .RE
491 .PP
492 to determine the program to use to perform the HTTP retrieval. This program
493 is invoked with one argument: the URL of the content to retrieve. The program
494 should write the content to standard out, and should terminate with a status of zero if the retrieval is successful and a non\-zero exit status otherwise.
495 .PP
496 .SS "The Content Cache"
497 When
498 .B mhstore
499 encounters an external content containing a
500 \*(lqContent-ID:\*(rq field, and if the content allows caching, then
501 depending on the caching behavior of
502 .BR mhstore ,
503 the content might be read from or written to a cache.
504 .PP
505 The caching behavior of
506 .B mhstore
507 is controlled with the
508 .B \-rcache
509 and
510 .B \-wcache
511 switches, which define the policy for reading from,
512 and writing to, the cache, respectively. One of four policies may be
513 specified: \*(lqpublic\*(rq, indicating that
514 .B mhstore
515 should make use
516 of a publically-accessible content cache; \*(lqprivate\*(rq, indicating
517 that
518 .B mhstore
519 should make use of the user's private content cache;
520 \*(lqnever\*(rq, indicating that
521 .B mhstore
522 should never make use of
523 caching; and, \*(lqask\*(rq, indicating that
524 .B mhstore
525 should ask the user.
526 .PP
527 There are two directories where contents may be cached: the profile entry
528 \*(lqnmh-cache\*(rq names a directory containing world-readable contents, and,
529 the profile entry \*(lqnmh-private-cache\*(rq names a directory containing
530 private contents. The former should be an absolute (rooted) directory
531 name.
532 .PP
533 For example,
534 .PP
535 .RS 5
536 nmh-cache: /tmp
537 .RE
538 .PP
539 might be used if you didn't care that the cache got wiped after each
540 reboot of the system. The latter is interpreted relative to the user's
541 nmh directory, if not rooted, e.g.,
542 .PP
543 .RS 5
544 nmh-private-cache: .cache
545 .RE
546 .PP
547 (which is the default value).
548 .SS "User Environment"
549 Because the environment in which
550 .B mhstore
551 operates may vary for
552 different machines,
553 .B mhstore
554 will look for the environment variable
555 .BR $MHSTORE .
556 If present, this specifies the name of an additional
557 user profile which should be read. Hence, when a user logs in on a
558 particular machine, this environment variable should be set to
559 refer to a file containing definitions useful for that machine.
560 Finally,
561 .B mhstore
562 will attempt to consult
563 .PP
564 .RS 5
565 %nmhetcdir%/mhn.defaults
566 .RE
567 .PP
568 which is created automatically during
569 .B nmh
570 installation.
571 .PP
572 See "Profile Lookup" in
573 .IR mh-profile (5)
574 for the profile search order, and for how duplicate entries are treated.
575 .SH EXAMPLES
576 .SS Decoding RFC 2047-encoded file names
577 The improper RFC 2047 encoding of file name parameters can be replaced
578 with correct RFC 2231 encoding using
579 .BR mhfixmsg ,
580 either permanently or ephemerally, e.g.,
581 .PP
582 .RS
583 .nf
584 mhfixmsg -outfile - | mhstore -auto -clobber ask -file -
585 .fi
586 .RE
587 .PP
588 The
589 .BI \-clobber ask
590 is not necessary, though recommended to avoid silently overwriting an existing
591 file.
592 .SH FILES
593 .B mhstore
594 looks for additional profile files in multiple locations: absolute
595 pathnames are accessed directly, tilde expansion is done on usernames,
596 and files are searched for in the user's
597 .I Mail
598 directory as specified in their profile. If not found there, the directory
599 .RI \*(lq %nmhetcdir% \*(rq
600 is checked.
601 .PP
602 .fc ^ ~
603 .nf
604 .ta \w'%nmhetcdir%/ExtraBigFileName 'u
605 ^$HOME/\&.mh\(ruprofile~^The user profile
606 ^$MHSTORE~^Additional profile entries
607 ^%nmhetcdir%/mhn.defaults~^System default MIME profile entries
608 .fi
609 .SH "PROFILE COMPONENTS"
610 .fc ^ ~
611 .nf
612 .ta 2.4i
613 .ta \w'ExtraBigProfileName 'u
614 ^Path:~^To determine the user's nmh directory
615 ^Current\-Folder:~^To find the default current folder
616 ^nmh-access-ftp:~^Program to retrieve contents via FTP
617 ^nmh-access-url:~^Program to retrieve contents via HTTP
618 ^nmh-cache~^Public directory to store cached external contents
619 ^nmh-private-cache~^Personal directory to store cached external contents
620 ^nmh-storage~^Directory to store contents
621 ^mhstore-store-<type>*~^Template for storing contents
622 .fi
623 .SH "SEE ALSO"
624 .IR mhbuild (1),
625 .IR mhfixmsg (1),
626 .IR mhlist (1),
627 .IR mhshow (1),
628 .IR sendfiles (1)
629 .SH DEFAULTS
630 .nf
631 .RB ` +folder "' defaults to the current folder"
632 .RB ` msgs "' defaults to cur"
633 .RB ` \-noauto '
634 .RB ` \-clobber\ always '
635 .RB ` \-nocheck '
636 .RB ` \-rcache\ ask '
637 .RB ` \-wcache\ ask '
638 .RB ` \-verbose '
639 .SH CONTEXT
640 If a folder is given, it will become the current folder. The last
641 message selected will become the current message.
642 .SH BUGS
643 Partial messages contained within a multipart content are not reassembled.