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