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, p...@foxharp.boston.ma.us (arlington, ma, where it's 39.9 degrees) _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers