nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] Request for new command: addresses


From: Paul Fox
Subject: Re: [Nmh-workers] Request for new command: addresses
Date: Wed, 28 May 2014 07:22:47 -0400

david wrote:
 > Norm wrote:
 > 
 > > There are still a couple of minor problems:
 > > 
 > >    As I commented earlier, in this thread, there is nothing to prevent
 > >    some future version of repl using a different prompt. One way
 > >    to prevent that would be to put "Reply to:" in the man page.
 > >    I herewith request that.
 > 
 > How's this?
 > 
 >    The  -query switch modifies the action of -nocc type switch by interac‐
 >    tively asking you if each address that normally would be placed in  the
 >    “To:”  and  “cc:”  list should actually be sent a copy.  This is useful
 >    for special-purpose replies.  The prompt format is
 > 
 >         Reply to address?
 > 
 >    That prompt will not change, so that scripts can rely on it.  Note that
 >    the  position  of  the  -cc and -nocc switches, like all other switches
 >    which take a positive and negative form, is important.

i'm not convinced that piping "yes n" to a clearly interactive
command turns it into a "scriptable interface".  it's more akin to
screen scraping.  there's no particular reason for "Reply to address?"
to change any time soon, but also no reason for us to promise that
it won't.  if the feature is important enough to lock down the
UI, then it's probably enough to do correctly.

paul

 > 
 > ("address" in the prompt is italicized.)  I also added a comment
 > to the code.  It's just on master:  if OK, I don't see a reason
 > not to add this to 1.6.
 > 
 > >    repl returns a non-zero exit code because of the the "-editor false"
 > >    arguments , as well as to actual errors, such as an
 > >    unreadable message. The script blissfully ignores the latter.
 > >    I don't think that problem is worth pursuing.
 > 
 > It would be really easy to have repl exit with status of 2
 > instead of 1 for the "-editor false" case or any other failure
 > of the editor.  But if we're going to touch that, I think that
 > we should consider passing back the exit status from the editor
 > (or attempt to invoke the editor, so return 127 if not found).
 > editfile() currently maps any failure to a status of -2,
 > starting at line 734 in uip/whatnowsbr.c.  Its callers map that
 > to 1.  (buildfile() maps it to -1 but its caller ignores the
 > return value.)
 > 
 > David
 > 
 > _______________________________________________
 > Nmh-workers mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=----------------------
 paul fox, address@hidden (arlington, ma, where it's 44.2 degrees)



reply via email to

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