[Sorry for this series of bug reports after nmh-1.0 was just released.
Unfortunately, the only time I can really dig into MH or nmh details is
when I need to document them for updates to the online "MH & xmh" book.]
Synopsis: the refile and rmm -unlink switches don't unlink the message
if an "rmmproc" is defined in the MH profile; instead, the rmmproc runs
as usual. In refile, you have to use both -unlink and -normmproc...
and, in rmm, there is no workaround I can find. This seems unintuitive
and even dangerous to me.
Details: The refile(1) manpage for nmh-1.0 says:
Alternately, if you wish for \fIrefile\fR to really remove the files
representing these messages from the source folder, you can use the
`-unlink' switch (not to be confused with the -link switch). But
messages removed by this method cannot be later recovered.
...
If you prefer a more sophisticated method of `removing' the messages
from the source folder, you can define the \fIrmmproc\fR profile
component.
rmm(1) says about the same thing.
If I have an "rmmproc" entry in my .mh_profile, refile and rmm
always seem to use it, even if I give "-unlink". Example:
% scan +temp
1+ 02/14 To:nmh-workers@ma flist bug (nmh-1.0): relative folder names
% ls -F `mhpath`
1 DELETE/
% mhparam rmmproc
/tmp/rmm-stub
% cat /tmp/rmm-stub
#!/bin/sh
echo "Hello from rmm-stub. pwd=`pwd`, args are $*"
% refile -unlink +inbox
Hello from rmm-stub. pwd=/home/jpeek/.Mail/temp, args are 1
% scan
1+ 02/14 To:nmh-workers@ma flist bug (nmh-1.0): relative folder names
% vi .mh_profile
...comment-out the rmmproc entry...
% mhparam rmmproc
% scan
1+ 02/14 To:nmh-workers@ma flist bug (nmh-1.0): relative folder names
% refile -unlink +inbox
% scan
scan: no messages in temp
% ls -F `mhpath`
DELETE/
% which refile
/usr/local/nmh/bin/refile
% refile -version
refile -- nmh-1.0 [compiled on jpeek.com at Sat Feb 13 17:17:22 GMT 1999]
This might be called a "feature" if there were some way for the rmmproc
to know that -unlink has been used. But, unless there's an undocumented
environment variable or something, having an rmmproc means that -unlink
becomes basically a no-op.
Sorry I don't have time to dig in and suggest a fix. (I barely have time
to update the book.) If I'm wrong about this bug, please let me know!!
Otherwise, if you agree with this, maybe you can suggest a fix? Thanks.
Jerry
--
Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/~jpeek/
