-notify success,failure
I guess that the new -notify and -ret would be passed to send(1),
and from there to post(8)? One gotcha that not all of the MH commands
handle well is how to un-do a switch from the command line that's already
been set in the MH profile. (Like, once you use "repl -format", you
can't use "-noformat" later :-(.) For instance, if your MH profile has:
send: -notify success,failure
you need to be able to stop DSNs for some message... with something like:
What now? send -notify never
or What now? send -nonotify
The other question is whether the values given at "What now? " should:
- completely override any earlier settings, or
- be _appended to_ any earlier settings
In other words, what happens when you pass the following parameters to
"send" (from either the MH profile, the "What now? " prompt, or both):
-notify success,failure -notify delay
Does it send notifications for SUCCESS FAILURE DELAY, or just DELAY?
You might be able to make your code really flexible by doing it the
same way that repl(1) handles -cc and -nocc. Those switches let you
get a lot of combinations... for example, in:
repl -nocc all -cc me -cc to
The "-nocc all" stops all cc's. Then the "-cc me -cc to" adds cc's to
two of the addresses. So users can have "-nocc all" in an MH profile,
and use "-cc me -cc to" when they invoke repl. Very nice.
In your code, a -nonotify switch would be a little hard to type (nono),
but it would give users more flexibility. For example, if the MH
profile had this as a default:
send: -notify success,failure
and you didn't want to know that a message succeeded, you could say:
What now? send -nonotify success
and only have the failure notification used. Hmmm. This seems sort
of hard to code, but the flexibility could make life easier for users.
I guess that "-notify never" would override any setting of "-ret",
so you wouldn't need a "-noret" or "-ret none" switch.
Hope I didn't just discourage you from taking this project on at all! ;-)
--Jerry Peek, jerry(_at_)ora(_dot_)com