MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
NAME
mhn - display/list/store/cache MIME messages
SYNOPSIS
mhn [+folder] [msgs] [-file file]
[-part number]... [-type content]...
[-show] [-noshow] [-list] [-nolist]
[-store] [-nostore] [-cache] [-nocache]
[-headers] [-noheaders] [-realsize] [-norealsize]
[-serialonly] [-noserialonly] [-form formfile]
[-pause] [-nopause] [-auto] [-noauto]
[-rcache policy] [-wcache policy] [-check] [-nocheck]
[-verbose] [-noverbose] [-version] [-help]
mhn-build file
[-ebcdicsafe] [-noebcdicsafe]
[-rfc934mode] [-norfc934mode]
DESCRIPTION
MHN SHOULD BE CONSIDERED DEPRECATED. IT IS RETAINED FOR THE
PURPOSE OF BACKWARD COMPATIBILITY, BUT EVERYONE SHOULD
MIGRATE TO USING THE COMMANDS MHSHOW, MHSTORE, AND MHLIST.
CHECK THE INDIVIDUAL MAN PAGES FOR DETAILS.
The mhn command allows you to display, list, store, or cache
the contents of a MIME (multi-media) messages.
mhn manipulates multi-media messages as specified in
RFC-2045 thru RFC-2049. Currently mhn only supports
encodings in message bodies, and does not support the
encoding of message headers as specified in RFC-2047.
The switches `-list', `-show', `-store', and `-cache' direct
the operation of mhn. Only one of these switches may be
used at a time. These switches are used to operate on the
content of each of the named messages. By using the `-part'
and `-type' switches, you may limit the scope of the given
operation to particular subparts (of a multipart content)
and/or particular content types.
The switch `-build' is used to construct a MIME message. It
is for backward compatibility and instructs mhn to execute
the mhbuild command. It is preferred that you use the
mhbuild command directly. See the mhbuild(1) man page for
details.
The option `-file file' directs mhn to use the specified
file as the source message, rather than a message from a
folder. If you specify this file as -, then mhn will accept
the source message on the standard input. Note that the
file, or input from standard input should be a validly
Page 1 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
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)).
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 `-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/external-body and once for the content
externally referenced.
Checking the Contents
The `-check' switch tells mhn to check each content for an
integrity checksum. If a content has such a checksum
(specified as a Content-MD5 header field), then mhn will
attempt to verify the integrity of the content.
Page 2 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
Listing the Contents
The `-list' switch tells mhn to list the table of contents
associated with the named messages.
The `-headers' switch indicates that a one-line banner
should be displayed above the listing. The `-realsize'
switch tells mhn 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 extra
information that is present in the message, such as comments
in the Content-Type header.
Showing the Contents
The `-show' switch tells mhn to display the contents of the
named messages.
The headers of each message are displayed with the mhlproc
(usually mhl), using the standard format file mhl.headers.
You may specify an alternate format file with the `-form
formfile' switch. If the format file mhl.null is specified,
then the display of the message headers is suppressed.
Next, the contents are extracted from the message and are
stored in a temporary file. Usually, the name of the
temporary file the word "mhn" followed by a string of
characters. Occasionally, the method used to display a
content (described next), requires that the file end in a
specific suffix. For example, the soffice command (part of
the StarOffice package) can be used to display MicroSoft
Word content, but it uses the suffix to determine how to
display the file. If no suffix is present, the file is not
correctly loaded. Similarily, older versions of the gs
command append a ".ps" suffix to the filename if one was
missing. As a result, these cannot be used to read the
default temporary file.
To get around this, your profile can contain lines of the
form:
mhn-suffix-<type>/<subtype>: <suffix>
or
mhn-suffix-<type>: <suffix>
to specify a suffix which can be automatically added to the
temporary file created for a specific content type. For
example, the following lines might appear in your profile:
mhn-suffix-text: .txt
Page 3 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
mhn-suffix-application/msword: .doc
mhn-suffix-application/PostScript: .ps
to automatically append a suffix to the temporary files.
The method used to display the different contents in the
messages bodies will be determined by a display string. To
find the display string, mhn will first search your profile
for an entry of the form:
mhn-show-<type>/<subtype>
to determine the display string. If this isn't found, mhn
will search for an entry of the form:
mhn-show-<type>
to determine the display string.
If a display string is found, any escapes (given below) will
be expanded. The result will be executed under /bin/sh,
with the standard input set to the content. The display
string may contain the following escapes:
%a Insert parameters from Content-Type field
%e exclusive execution
%f Insert filename containing content
%F %e, %f, and stdin is terminal not content
%l display listing prior to displaying content
%p %l, and ask for confirmation
%s Insert content subtype
%d Insert content description
%% Insert the character %
For those display strings containing the e- or F-escape, mhn
will execute at most one of these at any given time.
Although the F-escape expands to be the filename containing
the content, the e-escape has no expansion as far as the
shell is concerned.
When the p-escape prompts for confirmation, typing INTR
(usually control-C) will tell mhn not to display that
content. The p-escape can be disabled by specifying the
switch `-nopause'. Further, when mhn is display a content,
typing QUIT (usually control-\) will tell mhn to wrap things
up immediately.
Note that if the content being displayed is multipart, but
not one of the subtypes listed above, then the f- and F-
escapes expand to multiple filenames, one for each
subordinate content. Further, stdin is not redirected from
the terminal to the content.
Page 4 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
If a display string is not found, mhn has several default
values:
mhn-show-text/plain: %pmoreproc '%F'
mhn-show-message/rfc822: %pshow -file '%F'
If a subtype of type text doesn't have a profile entry, it
will be treated as text/plain.
mhn has default methods for handling multipart messages of
subtype mixed, alternative, parallel, and digest. Any
unknown subtype of type multipart (without a profile entry),
will be treated as multipart/mixed.
If none of these apply, then mhn will check to see if the
message has an application/octet-stream content with
parameter type=tar. If so, mhn will use an appropriate
command. If not, mhn will complain.
Example entries might be:
mhn-show-audio/basic: raw2audio 2>/dev/null | play
mhn-show-image: xv '%f'
mhn-show-application/PostScript: lpr -Pps
Note that when using the f- or F-escape, it's a good idea to
use single-quotes around the escape. This prevents
misinterpretation by the shell of any funny characters that
might be present in the filename.
Finally, mhn will process each message serially -- it won't
start showing the next message until all the commands
executed to display the current message have terminated. In
the case of a multipart content (of any subtype listed
above), the content contains advice indicating if the parts
should be displayed serially or in parallel. Because this
may cause confusion, particularly on uni-window displays,
the `-serialonly' switch can be given to tell mhn to never
display parts in parallel.
Showing Alternate Character Sets
Because a content of type text might be in a non-ASCII
character set, when mhn encounters a charset parameter for
this content, it checks if your terminal can display this
character set natively. Mhn checks this by examining the
the environment variable MM_CHARSET. If the value of this
environment variable is equal to the value of the charset
parameter, then mhn assumes it can display this content
without any additional setup. If this environment variable
is not set, mhn will assume a value of US-ASCII. If the
character set cannot be displayed natively, then mhn will
Page 5 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
look for an entry of the form:
mhn-charset-<charset>
which should contain a command creating an environment to
render the character set. This command string should
containing a single %s, which will be filled-in with the
command to display the content.
Example entries might be:
mhn-charset-iso-8859-1: xterm -fn '-*-*-medium-r-
normal-*-*-120-*-*-c-*-iso8859-*' -e %s
or
mhn-charset-iso-8859-1: '%s'
The first example tells mhn to start xterm and load the
appropriate character set for that message content. The
second example tells mhn that your pager (or other program
handling that content type) can handle that character set,
and that no special processing is needed beforehand.
Note that many pagers strip off the high-order bit or have
problems displaying text with the high-order bit set.
However, the pager less has support for single-octet
character sets. The source to less is available on many ftp
sites carrying free software. In order to view messages
sent in the ISO-8859-1 character set using less, put these
lines in your .login file:
setenv LESSCHARSET latin1
setenv LESS "-f"
The first line tells less to use the ISO-8859-1 definition
for determining whether a character is normal, control, or
binary. The second line tells less not to warn you if it
encounters a file that has non-ASCII characters. Then,
simply set the moreproc profile entry to less, and it will
get called automatically. (To handle other single-octet
character sets, look at the less (1) manual entry for
information about the LESSCHARDEF environment variable.)
Storing the Contents
The `-store' switch tells mhn to store the contents of the
named messages in native (decoded) format. Two things must
be determined: the directory to store the content, and the
filenames. Files are written in the directory given by the
Page 6 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
nmh-storage profile entry, e.g.,
nmh-storage: /tmp
If this entry isn't present, the current working directory
is used.
If the `-auto' switch is given, then mhn will check if the
message contains information indicating the filename that
should be used to store the content. This information
should be specified as the attribute name=filename in the
Content-Type header for the content you are storing. For
security reasons, this filename will be ignored if it begins
with the character '/', '.', '|', or '!', or if it contains
the character '%'. For the sake of security, this switch is
not the default, and it is recommended that you do NOT put
the `-auto' switch in your .mh_profile file.
If the `-auto' switch is not given (or is being ignored for
security reasons) then mhn will look in the user's profile
for a formatting string to determine how the different
contents should be stored. First, mhn will look for an
entry of the form:
mhn-store-<type>/<subtype>
to determine the formatting string. If this isn't found,
mhn will look for an entry of the form:
mhn-store-<type>
to determine the formatting string.
If the formatting string starts with a + character, then
content is stored in the named folder. A formatting string
consisting solely of a + character is interpreted to be the
current folder.
If the formatting string consists solely of a - character,
then the content is sent to the standard output.
If the formatting string starts with a '|', then the display
string will represent a command for mhn to execute which
should ultimately store the content. The content will be
passed to the standard input of the command. Before the
command is executed, mhn will change to the appropriate
directory, and any escapes (given below) in the display
string will be expanded.
Otherwise the formatting string will represent a pathname in
which to store the content. If the formatting string starts
with a '/', then the content will be stored in the full path
Page 7 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
given, else the file name will be relative to the value of
nmh-storage or the current working directory. Any escapes
(given below) will be expanded, except for the a-escape.
A command or pathname formatting string may contain the
following escapes. If the content isn't part of a multipart
(of any subtype listed above) content, the p-escapes are
ignored.
%a Parameters from Content-type (only valid with command)
%m Insert message number
%P Insert part number with leading dot
%p Insert part number without leading dot
%t Insert content type
%s Insert content subtype
%% Insert character %
If no formatting string is found, mhn will check to see if
the content is application/octet-stream with parameter
type=tar. If so, mhn will choose an appropriate filename.
If the content is not application/octet-stream, then mhn
will check to see if the content is a message. If so, mhn
will use the value +. As a last resort, mhn will use the
value %m%P.%s.
Example profile entries might be:
mhn-store-text: %m%P.txt
mhn-store-text: +inbox
mhn-store-message/partial: +
mhn-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
mhn-store-image/jpeg: %m%P.jpg
mhn-store-application/PostScript: %m%P.ps
Reassembling Messages of Type message/partial
When asked to store a content containing a partial message,
mhn will try to locate all of the portions and combine them
accordingly. The default is to store the combined parts as
a new message in the current folder, although this can be
changed using formatting strings as discussed above. Thus,
if someone has sent you a message in several parts (such as
the output from sendfiles), you can easily reassemble them
all into a single message in the following fashion:
% mhn-list 5-8
msg part type/subtype size description
5 message/partial 47K part 1 of 4
6 message/partial 47K part 2 of 4
7 message/partial 47K part 3 of 4
8 message/partial 18K part 4 of 4
% mhn-store 5-8
Page 8 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
reassembling partials 5,6,7,8 to folder inbox as message 9
% mhn-list -verbose 9
msg part type/subtype size description
9 application/octet-stream 118K
(extract with uncompress | tar xvpf -)
type=tar
conversions=compress
This will store exactly one message, containing the sum of
the parts. It doesn't matter whether the partials are
specified in order, since mhn will sort the partials, so
that they are combined in the correct order. But if mhn can
not locate every partial necessary to reassemble the
message, it will not store anything.
External Access
For contents of type message/external-body, mhn supports
these access-types:
afs
anon-ftp
ftp
local-file
mail-server
For the anon-ftp and ftp access types, mhn will look for the
nmh-access-ftp profile entry, e.g.,
nmh-access-ftp: myftp.sh
to determine the pathname of a program to perform the FTP
retrieval. This program is invoked with these arguments:
domain name of FTP-site
username
password
remote directory
remote filename
local filename
ascii or binary
The program should terminate with an exit status of zero if
the retrieval is successful, and a non-zero exit status
otherwise.
If this entry is not provided, then mhn will use a simple
built-in FTP client to perform the retrieval.
Page 9 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
The Content Cache
When mhn encounters an external content containing a
Content-ID: field, and if the content allows caching, then
depending on the caching behavior of mhn, the content might
be read from or written to a cache.
The caching behavior of mhn is controlled with the `-rcache'
and `-wcache' switches, which define the policy for reading
from, and writing to, the cache, respectively. One of four
policies may be specified: public, indicating that mhn
should make use of a publically-accessible content cache;
private, indicating that mhn should make use of the user's
private content cache; never, indicating that mhn should
never make use of caching; and, ask, indicating that mhn
should ask the user.
There are two directories where contents may be cached: the
profile entry nmh-cache names a directory containing world-
readable contents, and, the profile entry nmh-private-cache
names a directory containing private contents. The former
should be an absolute (rooted) directory name. For example,
nmh-cache: /tmp
might be used if you didn't care that the cache got wiped
after each reboot of the system. The latter is interpreted
relative to the user's nmh directory, if not rooted, e.g.,
nmh-private-cache: .cache
(which is the default value).
Caching the Contents
When you encounter a content of type message/external-body
with access type mail-server, mhn will ask you if may send a
message to a mail-server requesting the content, e.g.,
% show 1
Retrieve content by asking mail-server@...
SEND file
? yes
mhn: request sent
Regardless of your decision, mhn can't perform any other
processing on the content.
However, if mhn is allowed to request the content, then when
it arrives, there should be a top-level Content-ID: field
which corresponds to the value in the original
Page 10 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
message/external-body content. You should now use the `-
cache' switch to tell mhn to enter the arriving content into
the content cache, e.g.,
% mhn-cache 2
caching message 2 as file ...
You can then re-process the original message/external-body
content, and the right thing should happen, e.g.,
% show 1
...
User Environment
Because the display environment in which mhn operates may
vary for different machines, mhn will look for the
environment variable $MHN. If present, this specifies the
name of an additional user profile which should be read.
Hence, when a user logs in on a particular display device,
this environment variable should be set to refer to a file
containing definitions useful for the given display device.
Normally, only entries that deal with the methods to display
different content type and subtypes
mhn-show-<type>/<subtype>
mhn-show-<type>
need be present in this additional profile. Finally, mhn
will attempt to consult one other additional user profile,
e.g.,
/usr/freeware/lib/nmh/etc/mhn.defaults
which is created automatically during nmh installation.
FILES
$HOME/.mh_profile The user profile
$MHN Additional profile entries
/usr/freeware/lib/nmh/etc/mhn.defaultSystem default MIME profile entries
/usr/freeware/lib/nmh/etc/mhl.headersThe headers template
PROFILE COMPONENTS
Path: To determine the user's nmh directory
Current-Folder: To find the default current folder
mhlproc: Default program to display message headers
nmh-access-ftp: Program to retrieve contents via FTP
nmh-cache Public directory to store cached external contents
nmh-private-cache Personal directory to store cached external contents
mhn-charset-<charset>Template for environment to render character sets
mhn-show-<type>* Template for displaying contents
nmh-storage Directory to store contents
Page 11 (printed 2/1/01)
MHN(1) [nmh-1.0.4] (MH.6.8) MHN(1)
mhn-store-<type>* Template for storing contents
moreproc: Default program to display text/plain content
SEE ALSO
mhbuild(1), mhl(1), sendfiles(1)
RFC-934:
Proposed Standard for Message Encapsulation,
RFC-2045:
Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies,
RFC-2046:
Multipurpose Internet Mail Extensions (MIME) Part Two:
Media Types,
RFC-2047:
Multipurpose Internet Mail Extensions (MIME) Part Three:
Message Header Extensions for Non-ASCII Text,
RFC-2048:
Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures,
RFC-2049:
Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples.
DEFAULTS
`+folder' defaults to the current folder
`msgs' defaults to cur
`-noauto'
`-nocache'
`-nocheck'
`-form mhl.headers'
`-headers'
`-pause'
`-rcache ask'
`-realsize'
`-noserialonly'
`-show'
`-noverbose'
`-wcache ask'
CONTEXT
If a folder is given, it will become the current folder.
The last message selected will become the current message.
BUGS
Partial messages contained within a multipart content are
not reassembled with the `-store' switch.
Page 12 (printed 2/1/01)
