MHSHOW(1)
π MHSHOW(1) π
General Commands Manual Β· section 1 Β· and yes bestie, it's that page
okay so hi π«Ά this is the manual for mhshow, and i'm gonna walk you through the whole thing like we're texting, because you deserve to actually get it instead of staring at dense grey text like π. no cap, this one's long, so buckle up. π
πΈ NAME πΈ
mhshow β display nmh MIME messages β¨
like. that's the whole job. it shows you MIME messages. iconic behavior honestly. π
π¦ SYNOPSIS π¦
mhshow [-help] [-version] [+folder] [msgs] [-file file] [-part number]
... [-type content] ... [-prefer content] ... [-noprefer]
[-concat | -noconcat] [-textonly | -notextonly] [-inlineonly |
-noinlineonly] [-header | -noheader] [-form formfile] [-markform
formfile]
that's the entire vibe of how you call it, preserved character for character, because i would never do you dirty like that. π
π DESCRIPTION π
so mhshow displays the contents of a MIME (multi-media) message, or a whole collection of messages. yes, contents. it's the "show me what's actually in here" girlie.
mhshow manipulates multi-media messages as specified in RFC 2045 to RFC 2049. but here's the tea, bestie: currently mhshow only supports encodings in message bodies, and it does not support the encoding of message headers as specified in RFC 2047. so heads up on that. π
by default, mhshow will display only the text parts of a message that are not marked as attachments. that's the default, okay? you can change it with the -notextonly and -noinlineonly switches. and on top of that, by using the -part, -type, and -prefer switches, you can limit and reorder the set of parts to be displayed, based on part number and/or content type. also super important: the inclusion of any -part or -type switches will override the default settings of -textonly and -inlineonly. periodt. π
the -header switch controls whether mhshow will print a message separator header before each message that it displays. and the header format can be controlled using -headerform, to specify a file containing mh-format(5) instructions. a copy of the built-in default headerform can be found in /etc/nmh/mhshow.header, for reference. also, in addition to the normal set of mh-format(5) instructions, a "%{folder}" escape provides a string representing the current folder. cute, right? πΈ
by default, mhshow will concatenate all content under one pager. but if you want each part to be displayed separately, you can override the default behavior with -noconcat. main character energy: each part gets its own moment. β¨
the -file file switch directs mhshow to use the specified file as the source message, rather than a message from a folder. and if you specify this file as β-β, then mhshow will accept the source message on the standard input. π₯ note that the file, or input from standard input, should be a validly 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)).
the -part switch can be given (one or more times) to restrict the set of subparts that will be displayed. (obviously with no -part switches, all parts will be considered.) if a -part switch specifies a specific subpart (i.e., a "leaf" in the tree of MIME parts), then that part will always be displayed. and if a -part switch references a multipart/alternative part, then (in the absence of a -type switch) only the default subpart of that multipart will be displayed. π³
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 only for 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. π’
the -type switch can also be used to restrict (or, when used in conjunction with -part, to further restrict) the display of parts according to content type. one or more -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). π
using either -part or -type switches alone will cause either switch 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. math girlies rise. π§
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:
textβ subtypes:plain,enrichedmultipartβ subtypes:mixed,alternative,digest,parallelmessageβ subtypes:rfc822,external-bodyapplicationβ subtypes:octet-stream,postscriptimageβ subtypes:jpeg,gif,pngaudioβ subtypes:basicvideoβ subtypes:mpeg
a legal MIME message must contain a subtype specification. no subtype, no service. π
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. yes, twice. i don't make the rules. π
in the absence of -prefer, mhshow will select the "best" displayable subpart from multipart/alternative content. the -prefer switch can be used (one or more times, in order of ascending preference) to let MH know which content types from a multipart/alternative MIME part are preferred by the user, in order to override the default selection for display. for example, mail is often sent containing both plaintext and HTML-formatted versions of the same content, and the HTML version is usually indicated to be the "best" format for viewing. using β-prefer text/plainβ will cause the plaintext version to be displayed if possible, but still allow display of the HTML part if there is no plaintext subpart available. using β-prefer text/plain -prefer image/pngβ would add a preference for PNG images, which might or might not ever appear in the same multipart/alternative section with text/plain. πΌοΈ
implementation note: RFC 2046 requires that the subparts of amultipart/alternativebe ordered according to "faithfulness to the original content", and MH by default selects the subpart ranked most "faithful" by that ordering. the-preferswitch reorders the alternative parts (only internally, never changing the message file) to move the user's preferred part(s) to the "most faithful" position. thus, when viewed bymhlist, the ordering ofmultipart/alternativeparts will appear to change when invoked with or without various-preferswitches. since the last of multiple-preferoptions "wins", a-preferon the command line will override any in a profile entry.
the -noprefer switch will cancel any previous -prefer switches. it's the "jk never mind" of switches. π
π» Unseen Sequence π»
if the profile entry βUnseen-Sequenceβ is present and non-empty, then mhshow will remove each of the messages shown from each sequence named by the profile entry. so it cleans up after itself like a good girlie. β¨
π¬ Showing the Contents π¬
the headers of each message are displayed with the mhlproc (usually mhl), using the standard format file, mhl.headers. you may specify an alternative format file with the -form formfile switch. and if the format file mhl.null is specified, then the display of the message headers is suppressed. poof. gone. π«₯
next, the contents are extracted from the message and are stored in a temporary file. usually, the name of the temporary file is the word βmhshowβ 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. similarly, 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:
mhshow-suffix-<type>/<subtype>: <suffix>
or
mhshow-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:
mhshow-suffix-text: .txt
mhshow-suffix-application/msword: .doc
mhshow-suffix-application/PostScript: .ps
to automatically append a suffix to the temporary files. π
the matching with the content type identifier is case-insensitive, both in mhshow-suffix-<type> and mhshow-show-<type> (below) profile entries. so don't stress about the caps, bestie. π
the method used to display the different contents in the messages bodies will be determined by a βdisplay stringβ. to find the display string, mhshow will first search your profile for an entry of the form:
mhshow-show-<type>/<subtype>
if this isn't found, mhshow will search for an entry of the form:
mhshow-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%{parameter}β insert the parameter value from the Content-Type field%fβ insert filename containing content%Fβ%f, and stdin is terminal not content%lβ display listing prior to displaying content%sβ insert content subtype%dβ insert content description%%β insert the character%
mhshow will execute at most one display string at any given time, and wait for the current display string to finish execution before executing the next display string. one at a time, no cutting the line. π
ββοΈ
the {parameter} escape is typically used in a command line argument that should only be present if it has a non-null value. it is highly recommended that the entire escape be wrapped in double quotes. shell parameter expansion can construct the argument only when it is non-null, e.g.,
mhshow-show-text/html: charset="%{charset}";
w3m ${charset:+-I $charset} -T text/html %F
and that's where we're at for now, bestie β there's more coming, so don't go anywhere π
okay so that example also shows how indentation means continuation: those two text lines combine into one single entry. π
And bestie, note that when you're dealing with text that's been converted internally by iconv(3), the βcharsetβ parameter will reflect the target character set of the text, not the original character set in the message. no cap.
Also note: 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. And furthermore, stdin is not redirected from the terminal to the content. periodt.
If a display string is not found, mhshow behaves as if these profile entries were supplied and supported:
mhshow-show-text/plain: %lmoreproc %F
mhshow-show-message/rfc822: %lshow -file %F
Note that βmoreprocβ is not supported in user profile display strings. π
If a subtype of type text doesn't have a profile entry, it gets treated as text/plain. simple as that. β¨
mhshow has default methods for handling multipart messages of subtype mixed, alternative, parallel, and digest. And any unknown subtype of type multipart (without a profile entry) will be treated as multipart/mixed. slay.
If none of these apply, then mhshow will check if the message has an application/octet-stream content with parameter βtype=tarβ. If so, it'll use an appropriate command. If not, mhshow will complain. π
Example entries might be:
mhshow-show-audio/basic: raw2audio 2>/dev/null | play
mhshow-show-image: xv %f
mhshow-show-application/PostScript: lpr -Pps
If an f- or F- escape is not quoted with single quotes, its expansion will be wrapped with single quotes. iykyk.
Finally, mhshow 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. one at a time, bestie. π
β¨ Showing Alternate Character Sets β¨
If mhshow was built with iconv(3), then all text/plain parts of the message(s) will be displayed using the character set of the current locale. See mhparam(1) for how to determine whether your nmh installation includes iconv(3) support. To convert text parts other than text/plain, or if mhshow was not built with iconv, an external program can be used, as described next. π
Because a content of type text might be in a non-ASCII character set, when mhshow encounters a βcharsetβ parameter for this content, it checks if your terminal can display this character set natively. mhshow checks this by examining the current character set defined by the locale(1) environment variables. If the value of the locale character set is equal to the value of the charset parameter, then mhshow assumes it can display this content without any additional setup. If the locale is not set properly, mhshow will assume a value of βUS-ASCIIβ. If the character set cannot be displayed natively, then mhshow will look for an entry of the form:
mhshow-charset-<charset>
which should contain a command creating an environment to render the character set. This command string should contain a single β%sβ, which will be filled-in with the command to display the content.
Example entries might be:
mhshow-charset-iso-8859-1: xterm -fn '-*-*-medium-r-normal-*-*-120-*-*-c-*-iso8859-*' -e %s
or
mhshow-charset-iso-8859-1: '%s'
The first example tells mhshow to start xterm and load the appropriate character set for that message content. The second example tells mhshow that your pager (or other program handling that content type) can handle that character set, and that no special processing is needed beforehand. iconic. β¨
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. For example, messages encoded in the ISO-8859-1 character set can be viewed using less, with these environment variable settings:
LESSCHARSET latin1
LESS -f
The first setting tells less to use the ISO-8859-1 definition to determine whether a character is βnormalβ, βcontrolβ, or βbinaryβ. The second setting 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.) π
β¨ External Access β¨
For contents of type message/external-body, mhshow supports these access-types:
afsanon-ftpftplocal-filemail-serverurl
For the βanon-ftpβ and βftpβ access types, mhshow 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.
For the βurlβ access-type, mhshow will look for the βnmh-access-urlβ profile entry. See mhstore(1) for more details.
β¨ User Environment β¨
Because the display environment in which mhshow operates may vary for different machines, mhshow will look for the environment variable MHSHOW. 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
mhshow-show-<type>/<subtype>
mhshow-show-<type>
need be present in this additional profile. Finally, mhshow will attempt to consult
/etc/nmh/mhn.defaults
which is created automatically during nmh installation.
See "Profile Lookup" in mh-profile(5) for the profile search order, and for how duplicate entries are treated.
β¨ Content-Type Marker β¨
mhshow will display a marker containing information about the part being displayed next. The default marker can be changed using the -markform switch to specify a file containing mh-format(5) instructions to use when displaying the content marker. A copy of the default markform can be found in /etc/nmh/mhshow.marker, for reference. In addition to the normal set of mh-format(5) instructions, the following component escapes are supported:
partβ returns string β MIME part numbercontent-typeβ returns string β MIME Content-Type of partdescriptionβ returns string β Content-Description headerdispositionβ returns string β Content disposition (attachment or inline)ctype-<PARAM>β returns string β Value of<PARAM>from Content-Type headercdispo-<PARAM>β returns string β Value of<PARAM>from Content-Disposition header%(size)β returns integer β The size of the decoded part, in bytes%(unseen)β returns boolean β Returns true for suppressed parts
In this context, the %(unseen) function indicates whether mhshow has decided to not display a particular part due to the -textonly or -inlineonly switches.
All MIME parameters and the βContent-Descriptionβ header will have RFC 2231 decoding applied and be converted to the local character set.
β¨ FILES β¨
mhshow looks for all format files and mhn.defaults in multiple locations: absolute pathnames are accessed directly, tilde expansion is done on usernames, and files are searched for in the user's Mail directory, as specified in their profile. If not found there, the directory /etc/nmh is checked.
$HOME/.mh_profileβ The user profile$MHSHOWβ Additional profile entries/etc/nmh/mhn.defaultsβ System default MIME profile entries/etc/nmh/mhl.headersβ The headers template/etc/nmh/mhshow.markerβ Example content marker/etc/nmh/mhshow.headerβ Example message separator header
β¨ PROFILE COMPONENTS β¨
Path:β To determine the user's nmh directoryCurrent-Folder:β To find the default current folderUnseen-Sequence:β To name sequences denoting unseen messagesmhlproc:β Default program to display message headersnmh-access-ftp:β Program to retrieve contents via FTPnmh-access-url:β Program to retrieve contents via HTTPmhshow-charset-<charsβ Template for environment to render character setsmhshow-show-<type>*β Template for displaying contentsmoreproc:β Default program to display text/plain content
β¨ SEE ALSO β¨
iconv(3), mhbuild(1), mhl(1), mhlist(1), mhparam(1), mhstore(1), sendfiles(1)
β¨ DEFAULTS β¨
+folderdefaults to the current foldermsgsdefaults tocur-concat-textonly-inlineonly-form mhl.headers
β¨ CONTEXT β¨
If a folder is given, it will become the current folder. The last message selected will become the current message.
This page is from nmh-1.8, dated 2015-02-08, and it's literally the blueprint. πβ¨
π¦ where this page comes from
- alpine 3.24: nmh-doc 1.8-r3 Β· BSD-3-Clause
- epel 10: nmh 1.8-3.el10_1 Β· BSD
- epel 9: nmh 1.8-1.el9 Β· BSD
- fedora 43: nmh 1.8-9.fc43 Β· LicenseRef-Callaway-BSD
- fedora 44: nmh 1.8-10.fc44 Β· LicenseRef-Callaway-BSD
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms