scott@grlab.UUCP (Scott Blachowicz) (05/24/89)
1) Mail forwarding (with edit)
I used to use 'mail -f .' (or more precisely I bound the macro
'[mail-flags]-f .' to \CF) to forward mail to people with editing. It
seems that the newest mush (Mail User's Shell (6.5 4/17/89) [5/19/89])
and it ships my forwarded mail off without allowing me to edit it. Is
there a more graceful way to do this now other than dummying up some
indent_str's, using 'mail -i .', then setting indent_str's back for
normal replying?
2) Interrupt handling in the new await command.
It seems to interrupt the macro sequence for the following macro and
leave me in [line-mode]. Is it suppose to do that?
[line-mode]\nupdate\nawait\nsort -d\ncurses\n[first-msg]
I suppose a solution to this would be to use:
[line-mode]update\n[line-mode]await\n[sort-reverse]d[first-msg]
Thanx,
Scott Blachowicz
USPS: Graphicus UUCP: ...!hpubvwa!grlab!scott
150 Lake Str S, #206 VoicePh: 206/828-4691
Kirkland, WA 98033 FAX: 206/828-4236comp-mail-mush@srhqla.uucp (05/27/89)
From: "Barton E. Schaefer" <island!ucbcad!cse.ogc.edu!schaefer> In article <7330016@grlab.UUCP> you write: } 1) Mail forwarding (with edit) } I used to use 'mail -f .' (or more precisely I bound the macro } '[mail-flags]-f .' to \CF) to forward mail to people with editing. It } seems that the newest mush (Mail User's Shell (6.5 4/17/89) [5/19/89]) } and it ships my forwarded mail off without allowing me to edit it. Use '[mail-flags]-ef\n' # the -e is for "edit" The consensus of some earlier discussion was that $autoedit should not affect "mail -f", so to get editing you need to explicitly give -e. } 2) Interrupt handling in the new await command. } It seems to interrupt the macro sequence for the following macro and } leave me in [line-mode]. Is it suppose to do that? } [line-mode]\nupdate\nawait\nsort -d\ncurses\n[first-msg] It isn't the await command that's breaking the macro, it's the sort. Macros by definition abort if any component fails. If there is only one message in the mailbox, sort will fail with "not enough messages" or something like that. } I suppose a solution to this would be to use: } [line-mode]update\n[line-mode]await\n[sort-reverse]d[first-msg] That will do what you want, because if [sort-reverse] fails you will be left on the first (only) message, even though the macro aborts. If you try to do anything more, like ...await\n[sort-reverse]d[first-msg][display] then I'd expect that the [display] would not happen when only one message has come in, again because of the sort failure. } Thanx, } Scott Blachowicz } USPS: Graphicus UUCP: ...!hpubvwa!grlab!scott -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
comp-mail-mush@srhqla.uucp (05/28/89)
From: island!sun!ucbvax!hplabs.hp.com!hplsla!hpubvwa!grlab!scott (Scott Blachowicz) On May 26, 7:05, Barton E. Schaefer wrote: > Subject: Re: mail -f . & await cmd problems > > In article <7330016@grlab.UUCP> you write: > } 1) Mail forwarding (with edit) > } I used to use 'mail -f .' (or more precisely I bound the macro > } '[mail-flags]-f .' to \CF) to forward mail to people with editing. It > } seems that the newest mush (Mail User's Shell (6.5 4/17/89) [5/19/89]) > } and it ships my forwarded mail off without allowing me to edit it. > > Use '[mail-flags]-ef\n' # the -e is for "edit" I should've noticed that in the help for mail...oops. > } 2) Interrupt handling in the new await command. > } It seems to interrupt the macro sequence for the following macro and > } leave me in [line-mode]. Is it suppose to do that? > } [line-mode]\nupdate\nawait\nsort -d\ncurses\n[first-msg] > > It isn't the await command that's breaking the macro, it's the sort. > Macros by definition abort if any component fails. If there is only > one message in the mailbox, sort will fail with "not enough messages" > or something like that. But I've usually got at least 20-30 messages in my mail spool file... it's my "to-do" list... so the failure of the sort command isn't likely. It seems what's happening is that the await command is "failing" because of its termination via interrupt instead of mail arrival. I suppose that behavior is debatable. Could an option be added to 'await' to have it always return "success"? I don't know what restrictions the signal handling might impose on that, though... -- Scott Blachowicz USPS: Graphicus UUCP: ...!hpubvwa!grlab!scott 150 Lake Str S, #206 VoicePh: 206/828-4691 Kirkland, WA 98033 FAX: 206/828-4236