MHSTORE(1)

💖 MHSTORE(1) — the mhstore glow-up 💖

okay bestie, pull up a chair, because this is mhstore, a General Commands Manual classic, and she is iconic. no cap.

---

✨ NAME ✨

mhstore — store contents of nmh MIME messages into files. that's it, that's the whole job, and she does it flawlessly 💅

---

🎀 SYNOPSIS 🎀

mhstore [-help] [-version] [+folder] [msgs] [-file file] [-outfile
     outfile] [-part number] ...  [-type content] ...  [-prefer content]
     ...  [-noprefer] [-auto | -noauto] [-clobber always | auto | suffix |
     ask | never] [-verbose | -noverbose]

---

🌸 DESCRIPTION 🌸

so like, the mhstore command lets you store the contents of a whole collection of MIME (multi-media) messages into files or other messages. literally what it says on the tin.

mhstore manipulates multi-media messages as specified in RFC 2045 to RFC 2049. yes, the whole range. she read all of them. 📚

By default, mhstore will store all the parts of each message. Each part gets its own separate file. The header fields of the message are not stored — we're not doing that here. And by using the -part, -type, and -prefer switches, you can limit <em>and</em> reorder the set of parts to be stored, based on part number and/or content type. choose your own adventure, bestie ✨

The -file file switch directs mhstore to use the specified file as the source message, rather than a message from a folder. And if you specify this file as -, then mhstore will accept the source message on the standard input. so cozy 🫶

heads up though: 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. (if you need to convert a file in mail drop format to a folder of nmh messages, see inc(1) — she's got you.)

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. cute little nesting situation, we love to see it 🪆

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. she's gonna act on it regardless, periodt.

The -type switch can also be used to restrict (or, when used in conjunction with -part, to further restrict) the selection 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). first match only, she's decisive 💅

Using either -part or -type switches alone will cause either 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 up 🔥

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 — plain, enriched
• multipart — mixed, alternative, digest, parallel
• message — rfc822, external-body
• application — octet-stream, postscript
• image — jpeg, gif, png
• audio — basic
• video — 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. twice!! she needs to hear it twice, okay?? 😤

The -prefer switch will alter the part-ordering of multipart/alternative MIME sections in order to override the sender-imposed default ordering. The -prefer switch is functionally most important for mhshow, but is also implemented in mhlist and mhstore to make common part-numbering possible across all three programs. The last of multiple -prefer switches will have the highest priority. This allows the command line switches to override profile entries. See mhlist(1) and mhshow(1) for more information on -prefer. she's the same girl in three different outfits, iykyk 👑

The -noprefer switch will cancel any previous -prefer switches. erasing the whole vibe, respectfully 🧹

---

💾 Storing the Contents 💾

mhstore will store the contents of the named messages in "native" (decoded) format. Two things must be determined: the directory in which to store the content, and the filenames. Files are written in the directory given by the nmh-storage profile entry, e.g.,

nmh-storage: /tmp

If this entry isn't present, the current working directory is used. simple as that 🫶

If the -outfile switch is given, its argument is used for the filename to store <em>all</em> of the content, with - indicating standard output.

If the -auto switch is given, then mhstore 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 filename attribute in the Content-Disposition header or as the name attribute in the Content-Type header for the content you are storing.

⚠️ security girlie moment: for security reasons, this filename will be ignored if it begins with the character /, ., |, or !, or if it contains the character %. We also recommend using a nmh-storage profile entry or a -clobber switch setting other than the default of always to avoid overwriting existing files. protect your files, bestie, she's just looking out for you 💜

If the -auto switch is not given (or is being ignored for security reasons) then mhstore will look in the user's profile for a "formatting string" to determine how the different contents should be stored. First, mhstore will look for an entry of the form:

mhstore-store-<type>/<subtype>

to determine the formatting string. If this isn't found, mhstore will look for an entry of the form:

mhstore-store-<type>

to determine the formatting string. fallback queen 🌈

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 it represents a command for mhstore 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, mhstore will change to the appropriate directory, and any escapes (given below) in the formatting string will be expanded. The use of the %a sequence is not recommended because the user has no control over the Content-Type parameter data. she said what she said.

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 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. Note that if nmh-storage is not an absolute path, it will be relative to the folder that contains the message(s).

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, mhstore will check to see if the content is application/octet-stream with parameter type=tar. If so, mhstore will choose an appropriate filename. If the content is not application/octet-stream, then mhstore will check to see if the content is a message. If so, mhstore will use the value +. As a last resort, mhstore will use the value %m%P.%s. she always has a plan, okay?? a whole decision tree, a whole flowchart, a whole main character 🌟

Example profile entries might be:

mhstore-store-text: %m%P.txt
mhstore-store-text: +inbox
mhstore-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
mhstore-store-image/jpeg: %m%P.jpg
mhstore-store-application/PostScript: %m%P.ps

The -verbose switch directs mhstore to print out the names of files that it stores. For backward compatibility, it is the default. The -noverbose switch suppresses these printouts. loud and proud by default, shy on request 🙈

---

🗂️ Overwriting Existing Files 🗂️

The -clobber switch controls whether mhstore should overwrite existing files. The allowed values for this switch and corresponding behavior when mhstore encounters an existing file are:

• always — Overwrite existing file (default)
• auto — Create new file of form name-n.extension
• suffix — Create new file of form name.extension.n
• ask — Prompt the user to specify whether or not to overwrite the existing file
• never — Do not overwrite existing file

With auto and suffix, n is the lowest unused number, starting from one, in the same form. If a filename does not have an extension (following a .), then auto and suffix create a new file of the form name-n and name.n, respectively. With never and ask, the exit status of mhstore will be the number of files that were requested but not stored. yes, the exit status is a count. she's keeping receipts 🧾

With ask, if standard input is connected to a terminal, the user is prompted to respond yes, no, or rename, to whether the file should be overwritten. The responses can be abbreviated. If the user responds with rename, then mhstore prompts the user for the name of the new file to be created. If it is a relative path name (does not begin with /), then it is relative to the current directory. If it is an absolute or relative path to a directory that does not exist, the user will be prompted whether to create the directory. If standard input is not connected to a terminal, ask behaves the same as always. no terminal? no questions, just vibes and overwrites 💀

---

🌐 External Access 🌐

For contents of type message/external-body, mhstore supports these access-types:

• afs
• anon-ftp
• ftp
• local-file
• mail-server
• url

For the anon-ftp and ftp access types, mhstore will look for the nmh-access-ftp profile entry, e.g.,

nmh-access-ftp: myftp.sh

and that's where part 1 leaves you, bestie — part 2 is coming and it's so worth the wait 💖✨

So like, that program gets handed a whole lil lineup of arguments, and bestie, it's positional, so the order MATTERS:

• domain name of FTP-site
• username
• password
• remote directory
• remote filename
• local filename
• “ascii” or “binary”

And when it's done doing its thing? It needs to bounce with an exit status of zero if the retrieval worked out, and a non-zero exit status if it didn't. That's the whole vibe check. 🫶

---

For the “url” access types, mhstore goes looking for the “nmh-access-url” profile entry to figure out which program is gonna do the HTTP retrieval, like:

nmh-access-url: curl -L

That program gets invoked with exactly one argument: the URL of the content to retrieve. Then it should write the content to standard out, and terminate with a status of zero if the retrieval succeeded and a non-zero exit status otherwise. Same deal, different protocol. ✨

👤 User Environment 💖

Okay so real talk — the environment mhstore lives in can be different from machine to machine, so mhstore goes hunting for the environment variable MHSTORE. If it's there? It names an additional user profile that should be read too. So when you log in on some particular machine, you set that env var to point at a file full of definitions that are useful for that machine specifically. Customization, but make it per-host. 💅

And finally, mhstore will attempt to consult:

/etc/nmh/mhn.defaults

which is created automatically during nmh installation. No, you don't have to make it yourself. 👑

Go read "Profile Lookup" in mh-profile(5) for the profile search order, and for how duplicate entries are treated. iykyk.

---

✨ EXAMPLES ✨

🎀 Decoding RFC 2047-encoded file names 🎀

So the improper RFC 2047 encoding of file name parameters can be swapped out for the correct RFC 2231 encoding using mhfixmsg — either permanently or ephemerally, your call bestie, e.g.:

mhfixmsg -outfile - | mhstore -auto -clobber ask -file -

Now listen: the -clobberask is not necessary, though it is recommended — because otherwise you might silently overwrite an existing file and that's giving 💀. Protect your files, queen.

---

📁 FILES 📁

mhstore looks for additional profile files 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 it's not found there, the directory “/etc/nmh” gets checked. Last resort energy, but it's there for you. 🫶

• $HOME/.mh_profile — The user profile
• $MHSTORE — Additional profile entries
• /etc/nmh/mhn.defaults — System default MIME profile entries

---

🧩 PROFILE COMPONENTS 🧩

• Path: — To determine the user's nmh directory
• Current-Folder: — To find the default current folder
• nmh-access-ftp: — Program to retrieve contents via FTP
• nmh-access-url: — Program to retrieve contents via HTTP
• nmh-storage — Directory to store contents
• mhstore-store-<type>* — Template for storing contents

---

👀 SEE ALSO 👀

mhbuild(1), mhfixmsg(1), mhlist(1), mhshow(1), sendfiles(1)

Go read your siblings, they're iconic too. 🌸

---

🌟 DEFAULTS 🌟

• `+folder' defaults to the current folder
• `msgs' defaults to cur
• `-noauto'
• `-clobber always'
• `-verbose'

---

🌀 CONTEXT 🌀

If a folder is given, it will become the current folder. And the last message selected will become the current message. That's just how the lore works. ✨

---

💀 BUGS 💀

Partial messages contained within a multipart content are not reassembled. Not me being dramatic, that's just literally what it says. 😭

---

Okay that's the whole page bestie, you're officially an mhstore scholar now. 💖 This one's from the nmh-1.8 era, dated 2015-02-06, and it lives in section MHSTORE(1) — go forth and store your MIME content responsibly. 🎀✨