scs@vax3.iti.org (Steve Simmons) (04/04/89)
I know, I know -- it's already there in 2.2, right? :-)
But just in case it isn't: I use elm a lot from home. Even
at 2400 baud, waiting for the main menu screen to redraw itself
so I can quit is a pain. It'd really be nice if the 'c' and 'a'
commands (among others) would work when you're in the "little"
command mode that comes up after/while reading a message.
On another note, we ran out of /tmp space today and users lost
their messages (Elm 2.1 with some patches, BSD4.3 OS). Has
errorchecking been added to handle this?
Steve Simmons Just another midwestern boy
scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs
"Hey...you *can* get here from here!"rob@PacBell.COM (Rob Bernardo) (04/05/89)
In article <919@itivax.iti.org> scs@vax3.iti.org (Steve Simmons) writes:
+I know, I know -- it's already there in 2.2, right? :-)
Sorry to say "'fraid not".
+But just in case it isn't: I use elm a lot from home. Even
+at 2400 baud, waiting for the main menu screen to redraw itself
+so I can quit is a pain. It'd really be nice if the 'c' and 'a'
+commands (among others) would work when you're in the "little"
+command mode that comes up after/while reading a message.
At first glance adding 'a' as a "post-pager" mode command looks
like it shouldn't be a problem.
Elm being a MUA that babysits you, I wonder if allowing 'c'
in "post-pager" mode would be good. If you have ask=ON in your
elmrc, you really won't know whether the messages you have marked
for deletion are the ones you really want deleted, since you
can't see the index screen with those D's. Perhaps the availability
of the 'c' command in "post-pager" mode could be tied to
1. user level
2. whether or not ask=ON
3. whether or not there are any messages to be deleted.
or some combination thereof.
+On another note, we ran out of /tmp space today and users lost
+their messages (Elm 2.1 with some patches, BSD4.3 OS). Has
+errorchecking been added to handle this?
Not yet. This may be a complex task: all fwrites, fprintfs,
fcloses, etc. will need to be checked, and error information passed
up a chain of functions to the proper level where the error can be
appropriately dealt with. If any of those intermediate functions
already have a meaningful return code, we will need to redesign
things a bit. The ELM development team has ranked this as at a fairly
high priority, but there was just so much we could get done for the
elm 2.2 release.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiascs@vax3.iti.org (Steve Simmons) (04/06/89)
In article <4941@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: >In article <919@itivax.iti.org> scs@vax3.iti.org (Steve Simmons) writes: >+On another note, we ran out of /tmp space today and users lost >+their messages (Elm 2.1 with some patches, BSD4.3 OS). Has >+errorchecking been added to handle this? > >Not yet. This may be a complex task: all fwrites, fprintfs, >fcloses, etc. will need to be checked, and error information passed >up a chain of functions to the proper level where the error can be >appropriately dealt with. . . Yeah, I knew how difficult it was when I asked. I suspect one problem is the way elm makes use of temporary mailboxes while it processes. Since elm already indexes the mailbox, why not just have it use the one in /usr/spool/mail (or /usr/mail) until it actually has to modify it? This should cut down on the amount of disk io with mailboxes and the amount of /tmp in use -- many users open a window with elm and leave it there all day, needlessly filling up /tmp. Then one can rewrite a mailbox in place and never have to deal with the issue since, presumably, mailboxes would usually shrink. [[Yes, I know I can add mail to /usr/spool/mail/me. But that's write-append, which does not blow you away when you run out of disk.]] More could be said in this vein, but it might get a bit techie for this newsgroup. And since I don't have the time to work on it myself, prescribing a solution is kind of presumptuous. :-) Anyway, thanks for the quick response. Steve Simmons Just another midwestern boy scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs "Hey...you *can* get here from here!"
les@chinet.chi.il.us (Leslie Mikesell) (04/07/89)
In article <928@itivax.iti.org> scs@vax3.UUCP (Steve Simmons) writes: >>+On another note, we ran out of /tmp space today and users lost >>+their messages (Elm 2.1 with some patches, BSD4.3 OS). Has >>+errorchecking been added to handle this? >>Not yet. This may be a complex task: all fwrites, fprintfs, >>fcloses, etc. will need to be checked, and error information passed >>up a chain of functions to the proper level where the error can be >>appropriately dealt with. . . >Yeah, I knew how difficult it was when I asked. Instead of trying to make every function try to do the "right thing" on an error, how about just deleting the tmp file and lock and DO NOT delete the mailbox file as you bail out. The only thing that would make this even moderately difficult is the variable arguments to fprintf() which might prevent a simple macro solution. Dying with an error message may be a little unfriendly, but deleting mail accidentally is anti-social. Les Mikesell
ske@pkmab.se (Kristoffer Eriksson) (04/07/89)
In article <4941@pbhyf.PacBell.COM>, rob@PacBell.COM (Rob Bernardo) writes: > +On another note, we ran out of /tmp space today and users lost > +their messages (Elm 2.1 with some patches, BSD4.3 OS). Has > +errorchecking been added to handle this? > > Not yet. This may be a complex task: all fwrites, fprintfs, > fcloses, etc. will need to be checked, and error information passed > up a chain of functions to the proper level where the error can be > appropriately dealt with. Why not just check ferror() once in a while before doing anything that may irreversibly destroy information? -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
rob@PacBell.COM (Rob Bernardo) (04/08/89)
In article <8152@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: +In article <928@itivax.iti.org> scs@vax3.UUCP (Steve Simmons) writes: + +>>+On another note, we ran out of /tmp space today and users lost +>>+their messages (Elm 2.1 with some patches, BSD4.3 OS). Has +>>+errorchecking been added to handle this? + +>>Not yet. This may be a complex task: all fwrites, fprintfs, +>>fcloses, etc. will need to be checked, and error information passed +>>up a chain of functions to the proper level where the error can be +>>appropriately dealt with. . . + +>Yeah, I knew how difficult it was when I asked. + +Instead of trying to make every function try to do the "right thing" +on an error, how about just deleting the tmp file and lock and +DO NOT delete the mailbox file as you bail out. The only thing that +would make this even moderately difficult is the variable arguments +to fprintf() which might prevent a simple macro solution. Dying with +an error message may be a little unfriendly, but deleting mail accidentally +is anti-social. Hm. I thought the problem was one where the error wasn't detected at all. When an error is detected, elm does roughly follow the algorhithm you mention. -- Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
mike@pcsbst.UUCP (Mike Schroeder) (06/28/89)
how about implementing a (small) history mechanism for the '!' and '|' commands in ELM? Maybe I'm doing something wrong, but I've often been annoyed at having to type '|' 'unshar -d xxx' to every message in one of my news archives separately, when 'xxx' is always the same directory. It would be much more comfortable if ELM remembered the last command I piped a message to (or executed as shell escape) and presented that as default, letting me change it if I choose to. How about it, ELM team? Could this be in ELM 2.3? Cheers -- Mike Schroeder PCS-Mail: msc DOMAIN: msc@cochise.pcs.de (EUR) or msc@cochise.pcs.com (US) BANG: ..unido!pcsbst!msc (EUR) or ..pyramid!pcsbst!msc (US)