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