[Top][All Lists]

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

Re: [Nmh-workers] Future directions for nmh

From: Paul Fox
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Wed, 16 Mar 2016 22:58:48 -0400

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.



    case $me in
            if [ ! "$1" -a $PPID != "$(cat $PPIDFILE)" ]
                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

            echo $PPID >$PPIDFILE

 paul fox, address@hidden (arlington, ma, where it's 39.9 degrees)

reply via email to

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