sean@utoday.com (Sean Fulton) (03/28/91)
Although I haven't had time to really dig in and try to solve the problem, I've found a quick fix for the problem noted here about ELM dropping composed messages with ``Can't invoke /bin/vi'' after the user had successfully written and stored the message. This is worked for the last 24 hours and is not guaranteed to work on any system but my own, but it should. I found that putting /bin/vi (or /usr/bin/vi in our case) in a shell script with ``exit 0'' at the end and a trap for a clean exit at the top seems to work. I tried this after noting that users with editors other than vi were not having problems with ELM. ELM calls the script, the script calls vi $*, then exits 0, even if vi bombs. As I said, it seems to work. Any suggestions for a *real* solution to this problem would be appreciated. -- Sean Fulton sean@utoday.com UNIX Today! (516) 562-5430 /* The opinions expressed above are not those of my employer */
kevin@cfctech.cfc.com (Kevin Darcy) (04/04/91)
In article <1991Mar28.065651.20164@utoday.com> sean@utoday.com (Sean Fulton) writes: >Although I haven't had time to really dig in and try to solve the >problem, I've found a quick fix for the problem noted here about ELM >dropping composed messages with ``Can't invoke /bin/vi'' after the >user had successfully written and stored the message. > >This is worked for the last 24 hours and is not guaranteed to work on >any system but my own, but it should. I found that putting /bin/vi (or >/usr/bin/vi in our case) in a shell script with ``exit 0'' at the end >and a trap for a clean exit at the top seems to work. I tried this >after noting that users with editors other than vi were not having >problems with ELM. > >ELM calls the script, the script calls vi $*, then exits 0, even if vi >bombs. As I said, it seems to work. > >Any suggestions for a *real* solution to this problem would be >appreciated. Well, as Syd has already stated, the latest version (2.3 PL11) of Elm "fixes" the vi-return-code problem by just simply ignoring it. Thus, it is roughly equivalent to your solution, except that it doesn't use an extra process, nor require shell-wrapper mucking. This is not a perfect solution, of course, since it is possible that something REALLY BAD could actually happen to your file (e.g. maybe your kernel gets its inodes confused, or something), and it would be nice for Elm to tell you that before happily sending off e.g. a null_mail_message or e.g. some_random_ file. Unfortunately, UN*X editor implementations are anything -but- "standard", so it is difficult if not impossible for Elm to tell a "bogus" error from a real one... >-- >Sean Fulton sean@utoday.com >UNIX Today! (516) 562-5430 > /* The opinions expressed above are not those of my employer */ ------------------------------------------------------------------------------ kevin@cfctech.cfc.com | Kevin Darcy, Unix Systems Administrator ...sharkey!cfctech!kevin | Technical Services (CFC) Voice: (313) 948-4863 | Chrysler Corporation Fax: (313) 948-4975 | 27777 Franklin, Southfield, MI 48034 ------------------------------------------------------------------------------