david wrote: > 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. ... > > > 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.
that's likely what i'll do, though i'll investigate the procmail technique some more, as well. > Alternatively, something like this (completely untested)? > > msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && mhfixmsg $msgs but then i'd lose the default output of inc. > > 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. does mhfixmsg report (via exit code) whether it actually did anything or not? the man page doesn't say. if not, using anno would be difficult. paul =---------------------- paul fox, [email protected] (arlington, ma, where it's 30.4 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
