Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!EDDIE.MIT.EDU!think!compass!worley
From: think!compass!worley@EDDIE.MIT.EDU (Dale Worley)
Newsgroups: gnu.emacs
Subject: Why programs use the shell to start up a program
Message-ID: <8903231435.AA11955@galaxy.compass.com>
Date: 23 Mar 89 14:35:49 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 37

Generally the Un*x convention is that if a program wants to start an
inferior process, it has the shell do it, rather than doing a fork()
and exec() itself.  See, for example, the system() call.  You might
well wonder why this is done, since it costs time, and probably sets
up an additional process (is that really true?).  The reason is that
often the "program name" to run is obtained from the user or an
environment variable, and using the shell to process it gives
additional flexibility.  For instance:

The program may have a text string which is a command to run, complete
with arguments.  Then it can leave the problem of parsing the string
(and expanding wild cards, ~s, etc.) to the shell.

The program name may not be an absolute path, and thus the problem of
searching the path can be left to the shell.

The program name may be an alias (which, remember, the user thinks of
as a "command").  Figuring out aliases can be left to the shell.

The program name may be a real program name with some switches.  For
example, consider setting Emacs's lpr-command to "lpr -Pprinter2".
This will cause all of the Emacs print-* commands to print on
"printer2", but only if lpr-command's value is handed over to a shell
to crack apart into arguments.  A direct exec() of "lpr -Pprinter2"
will fail, since there is no file by that name.  (This trick is really
common, and is often used by users when setting shell variables, csh
aliases, and Emacs program-name variables.  That's why Un*x options go
after the program name but before the file names, rather than, say, at
the end of the command.)

Of course, much of this could be fixed by using the hack that Make
uses:  First check the command line for troublesome things (characters
that are special to the shell).  If there are none, the program is
invoked directly; if not, the problem is passed to the shell.

Dale Worley, Compass, Inc.                      worley@compass.com
The War on Drugs -- Prohibition for the '80s.