nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mhfixmsg invocation


From: David Levine
Subject: Re: [Nmh-workers] mhfixmsg invocation
Date: Wed, 19 Nov 2014 10:17:16 -0500

Paul F. wrote:

> i'm having a bit of trouble understanding how to integrate mhfixmsg
> into my workflow.
>
> i'd like to automatically run mhfixmsg on all mail, and, therefore,
> keep a backup of messages that it processes.  since i kind of abhor
> the ,nnn style of mh backups, i'd like to keep the mhfixmsg backups in
> a separate folder.  i think i can do this by setting mhfixmsg's
> rmmproc to a command that does something like:
>     cp $* $(mhpath +mhfixbackup new)
> is there a better way?

Not that I can think of, though I use the procmail approach so
haven't thought too much about it.

> to invoke mhfixmsg, using add-hook would normally seem like the best
> bet, except that it makes "refile -link" useless (for messages that
> mhfixmsg wants to process), as far as i can tell.  there's no way to
> disable add-hook for individual commands, right?

I don't think so, that's why there's the caveat in the mhfixmsg
man page.

> are hooks a useful
> enough feature that making them settable for individual commands
> (i.e. "inc:  -add-hook my-inc-add-hook") be desireable?
>
> the man page also suggests using something like:
>     alias inc='inc && mhfixmsg'
> but i don't see how this will work -- what if inc incorporates several
> messages?

Right, that should be fixed.

> mhfixmg by default will only act on 'cur', leaving the
> others unprocessed.  (i suppose "inc && mhfixmsg unseen" would work, at
> the cost of re-checking messages that i've manually added back into
> the unseen sequence.)

The cost of re-checking is so low that I would go that route.
Alternatively, something like this (completely untested)?

    msgs=`inc -format '%(msg)'`  &&  [ -n "$msgs" ]  &&  mhfixmsg $msgs

Let me know what you settle on and I'll update the man page.

> finally -- it feels like mhfixmsg should always add a new
> "X-mhfixmsg-was-here" header when it modifies a message, which would
> let me know that there is (or was) another version of the message file
> floating around somewhere.  was this considered?

No.  Off hand, I'm not fond of it.  You can do that with anno if
you want.

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]