The behavior of MHonArc is controled by resources.
Resources are set, or defined, by command-line options, environment
variables, or a resource file. For example, the MAXSIZE resource tells
MHonArc the maximum number of messages allowed in an archive. To set
the resource, you can use the
command-line option, the M2H_MAXSIZE envariable, or the
<MAXSIZE> resource file element.
See the Resources section of the documentation for more information.
If you are Vim user, <http://www.vim.org/>, a syntax file for MHonArc resource files is included in the examples directory (mhonarc.vim). To use it, copy mhonarc.vim to an appropriate location and add something like the following to your .vimrc file:
au BufNewFile,BufRead *.mrc so $HOME/share/vim/syntax/mhonarc.vim
Of course, change the pathname to mhonarc.vim to where ever you copied it to.
Now, any file with ".mrc" extension will put Vim into MHonArc resource file highlighting mode. The mode is best used with color-capable terminals.
For page layout resources, do something like the following in your resource file:
Notice the blank line. If you specify no content, MHonArc will fallback to the default value of the resource.
Only do the above for page layout related resources. For other resources, the above technique will have no effect, or it may cause unexpected results. See How do I reset an archive's resources to the default values? for more information on reseting resources to default values.
The following two commands will reset an archive to use default resource values:
prompt> mha-dbedit -nosaveresources -outdir /path/to/your/archive prompt> mhonarc -saveresources -editidx -outdir /path/to/your/archive
You could also include -rcfile option to the last step if you want to modify some resources from the default in case you want to reset some resources and not all of them.
newgetopt.pl comes with the standard Perl distribution. Check with your sys admin on where it is located (it should be in the default Perl search path).
v2.3 and later use Getopt::Long, which is included in the Perl 5 distribution.
No, but searching can be provided by another utility. The following list of search indexing tools have been used with MHonArc archives:
For more information, see the respective documentation of the search engine software of interest.
You may also want to check out the following:
No official ones. Several users have created home-grown interfaces to perform various tasks. An experimental, unsecure web admin tool comes in with the MHonArc distribution under the "admin" directory. I recommend searching the MHonArc mailing list archives for discussion about web interfaces.
No. Once a message is archived, the original can be stored away. MHonArc preserves all relevant information in its database. For possible recovering purposes, it is recommended to preserve original messages in a storage archive. This allows you to rebuild MHonArc archives in case of data corruption.
No. The archive database stores all resource settings. The only time you need to respecify the resource file is if changes are required in the layout of the archive.
When utilizing the OTHERINDEXES resource, the resource filenames listed in the main resource file are stored in the database, but the resources for each additional index are NOT. Hence, the resource files defining the additional indexes must be accesible.
Yes. MH mail folder processing is just processing a bunch of separate message files in a directory. MHonArc uses the MHPATTERN resource to determine which files to process. Therefore, all you need to do is redefine the MHPATTERN resource and pass the directory your message files are in when invoking MHonArc.
For example, say I want to process all files in a directory called "messages". I'd do the following:
prompt> mhonarc -mhpattern "^[^.]" messages
MHPATTERN can be any Perl regular expression. The one in the example matches any file not beginning with ".". This is to avoid the special files "." and ".." which are directories.
The other way to process individual message files is to do it one at a time. For example:
prompt> mhonarc -add < file1.822 prompt> mhonarc -add < file2.822 ...
Yes, but only in v2.0 or later (v2.0 beta releases do not have the capability). The syntax is something like the following:
prompt> mhonarc [options-here] -- -
The "--" tells MHonArc to terminate all command-line option processing and treat all following arguments as mail folders. The "-" signifies to use standard input as a mailbox source.
Since MHonArc can read a mailbox from stdin, this allows MHonArc to be part of a pipeline where MHonArc takes input from some preprocessor that massages some data to make it suitable for processing by MHonArc. For example:
prompt> mypreproc | mhonarc -- -
This warning is generated when a message does not contain any date information, or the date format used in the message is not recognized by MHonArc. The warning may also indicate an improper end of a message and start of a new message when processing a mailbox file. You may also want to see: Why does a message get split into mulitple messages with no headers?.
The "From ..." line (applicable in UUCP-style mailbox files) is the message separator and normally includes a date. The problem is that it is the message separator. The message separator is not part of actual message data, and the value of the message separator is controled by the MSGSEP resource. I.e. The MSGSEP resource can be set anything, so there is no reliable way to extract a date from it.
Do not lose hope. Provided in the extras directory of the MHonArc distribution (v2.1.1 and later) is a Perl program called prsfrom.pl by A.R. Burgers, email@example.com. The program will supply missing Date: and From: fields to mailboxes based upon the message separator line.
This usually implies that you have duplicate messages. MHonArc skips messages that have already been archived. A way to check if message duplication is the culprit, try the following on your mailbox:
prompt> grep -i '^message-id:' my.mbox | sort | uniq | wc -land
prompt> grep -i '^message-id:' my.mbox | sort | wc -l
If numbers printed by both commands differ, you have duplicate messages.