🚀 go-pugleaf

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