conrad wrote:
Ken> export MHCONTEXT context-$$
.. I live and learn, thanks.
Ken> in the above scenario, what do you EXPECT nmh to do?
Well, from experience, I expect it to do what I tell it, even if that's
not what I intend :-/
My preference would be for actions (rmm, refile, repl) to note there's
been a context change and ask for confirmation, I think. The machine is
i'd never considered changing MHCONTEXT either. but i think i'd
prefer the context be shared more often than i'd want it separate.
as usual, i have a half-assed solution to this problem which works
works surprisingly well in practice: all of my mh usage goes through
a multi-invocation wrapper script, mostly because i'd rather type one
letter commands. most invocations of my wrapper commands record their
parent's pid in a well-known file. the wrapper for rmm, when not
given a specific argument (i.e., "d", rather than "d 32") checks to
make sure its parent's pid is the same as what's recorded in the file --
if not, it warns me. this catches changes to cur and to the current
folder, and also simply reminds me that i've been running mh commands
elsewhere and that i should think a bit.
paul
excerpt:
me=${0##*/}
PPIDFILE=${MAILDIR:-$Mail}/.lastmhppid
...
case $me in
d)
if [ ! "$1" -a $PPID != "$(cat $PPIDFILE)" ]
then
(
echo Warning: last mh command started from different shell.
echo Will delete:
scan cur | map_binary
echo -n Current message may be WRONG! Hit y if okay...
) >&2
read ans
case $ans in
[yY]*)
;;
*)
exit
;;
esac
fi
;;
*)
echo $PPID >$PPIDFILE
;;
esac
=----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 39.9 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers