🚀 go-pugleaf

In article <1992Dec13.025955.13216@stb.info.com> michael@stb.info.com (Michael Gersten) writes:
   cs4w+@andrew.cmu.edu (Charles William Swiger) writes:
   >Excerpts from netnews.comp.sys.next.misc: 2-Nov-92 Re: emacs-18.59 pkg
   >for NeX.. by Stephen Anderson@sapir.c 
   >> It's been pointed out to me that the Emacs front end to emacs has the
   >> path /usr/bin/emacs built in as the place to find an emacs executable.
   >> This gives you (at least) three choices if you want to use it as a
   >
   >or (d) Rewrite EtermView.m to look for /usr/local/bin/emacs and then
   >/usr/bin/emacs; better yet, have it search through current users' search
   >path for 'emacs'....

   Or, better still, why not use the "system" call and let the shell find it,
   or use "execvp/execlp" library calls (the 'p' means search the entire path)?
   I'm suprised that more people don't use these.

Why not system(3) ? Because it has a ton of overhead and may do things
you don't want it to do. You should only use it for shell escapes in
you programs and those are fast becoming an anachronism in the age of
job control and security concerns. Why not execvp/execlp(3) ? Because
a user may have several versions of emacs on his system and and the
first one in his default path is not the one he wants to use with
Emacs and setting environment variables is notoriously painful for
Workspace launched applications.

Emacs 3.0 Does The Right Thing and allows you to set the path to the
emacs executable in the preferences. Maybe NeXT should start shipping
it with the OS.

        Carl Edman