Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!usc!csun!srhqla!uucp From: comp-mail-mush@srhqla.uucp Newsgroups: comp.mail.mush Subject: Re: mail -f . & await cmd problems Message-ID: <670@srhqla.UUCP> Date: 28 May 89 00:03:32 GMT Sender: uucp@srhqla.UUCP Lines: 37 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