MHLIST(1mh)

πŸ“¦
version 1.8 Β· 4 versions
, in debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– MHLIST πŸ’–

okay bestie, so mhlist is the nmh manual page for listing stuff about MIME messages, and it lives in section 1mh of the manual. that's it, that's the vibe check. πŸŽ€


✨ NAME ✨

mhlist β€” list information about nmh MIME messages 🌸


✨ SYNOPSIS ✨

mhlist [-help] [-version] [+folder] [msgs] [-file file] [-part number]
     ...  [-type content] ...  [-prefer content] ...  [-noprefer]
     [-headers | -noheaders] [-realsize | -norealsize] [-changecur |
     -nochangecur] [-verbose | -noverbose] [-disposition |
     -nodisposition]

✨ DESCRIPTION ✨

so mhlist literally lets you list info β€” think a table of contents, bestie, a whole little menu β€” about all the different parts of a bunch of MIME (that's multimedia, iykyk) messages. πŸ¦‹

mhlist messes with MIME messages exactly as specified in RFC 2045 to RFC 2049. (go peek at mhbuild(1) if you want the receipts πŸ“œ)

The -headers switch means a one-line banner gets displayed above the listing. that's the default, no cap. πŸ’…

The -realsize switch tells mhlist to evaluate the "native" (decoded) format of each content before listing it. why bother? because it gives you an accurate count β€” the tradeoff is just a tiny little delay. either way, sizes get expressed using SI prefix abbreviations (K/M/G/T), which are based on factors of 1000. math girlies rise 🧚

If the -verbose switch is present, then the listing shows any "extra" info hanging out in the message, like comments inside the Content-Type header. spill it all πŸ—£οΈ

If the -disposition switch is present, then the listing shows any relevant info from the Content-Disposition header. πŸ‘‘

The option -file file directs mhlist to use that specified file as the source message instead of pulling a message from a folder. and if you specify this file as -, then mhlist will accept the source message on standard input. πŸ’«

⚠️ heads up bestie: the file, or the 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, go see inc(1).)

By default, mhlist lists info about the entire message (every single one of its parts, periodt). but by using the -part, -type, and -prefer switches, you can limit and reorder the set of parts to be listed, based on part number and/or content type. you're the main character, you decide πŸ’…

A part specification is a series of numbers separated by dots. for example, in a multipart content containing three parts, these would be named 1, 2, and 3, respectively. and if part 2 was also a multipart content containing two parts, those would be named 2.1 and 2.2, respectively. so cute, so nested πŸͺ†

πŸ“Œ 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 the selection of parts according to content type β€” or, when used in conjunction with -part, to further restrict them. one or more -type switches will only select the first match from a multipart/alternative, even if there's more than one subpart that matches (one of) the given content type(s). first come, first served, we don't do duplicates here πŸ’€

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, not the union, of their separate match results. it's giving math class but make it MIME ✨

A content specification is a content type plus a subtype. the initial list of "standard" content types and subtypes lives in RFC 2046.

here's a lil list of commonly used contents, reproduced for you bestie:

Type         Subtypes
----         --------
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. non-negotiable 🚨

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. and further note: if the -type switch is used, and it's 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. two switches, one destiny 🫢

By default, the parts of a multipart/alternative part are listed in the reverse order of their placement in the message. so the listing ends up in decreasing order of preference, as defined in RFC 2046. πŸ’

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, so you can override the default preference order. thus, when viewed by mhlist, the ordering of multipart/alternative parts will appear to change when invoked with or without various -prefer switches. the -noprefer switch will cancel any previous -prefer switches. 🧹

The -prefer and -noprefer switches are functionally most important for mhshow, but they're also implemented in mhlist and mhstore to make common part numbering possible across all three programs. teamwork makes the dream work fr fr 🌈


✨ FILES ✨

  • $HOME/.mh_profile β€” the user profile 🏠

✨ PROFILE COMPONENTS ✨

  • Path: β€” to determine the user's nmh directory
  • Current-Folder: β€” to find the default current folder

✨ SEE ALSO ✨

mhbuild(1), mhshow(1), mhstore(1) 🌟


✨ DEFAULTS ✨

  • +folder defaults to the current folder
  • msgs defaults to cur
  • -headers
  • -realsize
  • -changecur
  • -noverbose
  • -nodisposition

✨ CONTEXT ✨

If a folder is given, it becomes the current folder. the last message selected becomes the current message β€” unless the -nochangecur option is specified. so like, watch out for that one bestie πŸ’–


and that's the whole page, you ate it πŸ’…βœ¨ this gorgeousness is from nmh-1.8, dated 2015-02-06 β€” yes she's an icon, she's a legend, and she is the moment πŸŽ€πŸ‘‘πŸ’–

πŸ“¦ where this page comes from