glenm@mako.UUCP (Glen McCluskey) (02/13/85)
Is there a good reason why an option cannot be added to ``make'' so that it will directly execute subcommands such as the compiler, instead of invoking a subshell? The only reason I can think of is to allow shell syntax such as pipes. There are enough cases where this is not necessary that the faster command startup time would seem to make it worthwhile. Some tests indicate that a vfork() and execvp() go about twice as fast as a system(). Glen McCluskey ..tektronix!mako!glenm
olson@fortune.UUCP (Dave Olson) (02/16/85)
I'm not sure about other versions of make, but Fortune Systems version (V7 plus some S3, plus local enhancements) will directly exec the command unless it determines that there are shell meta-characters in the command (>, &, ;, etc.). The easiest way to test this with any given version of make is to create a makefile like: --------- all: ps l --------- Then run make, and see if the ps reports both a "sh -c ps l", and a 'ps l'. Dave Olson, Fortune Systems UUCP: {ihnp4,ucbvax!dual}!fortune!olson ARPA: dual!fortune!olson@BERKELEY
thomas@utah-gr.UUCP (Spencer W. Thomas) (02/16/85)
In article <583@mako.UUCP> glenm@mako.UUCP (Glen McCluskey) writes: >Is there a good reason why an option cannot be added >to ``make'' so that it will directly execute subcommands >such as the compiler, instead of invoking a subshell? The version of make on our system (currently 4.2BSD, but this was also true in 4.1, thus probably in V7) does directly exec subcommands as long as they don't have shell meta-characters in them (=|^();&<>*?[]:$`'"\ and <newline>). -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) "A sharp tongue is the only edge tool that grows keener with constant use" - Washington Irving
guy@rlgvax.UUCP (Guy Harris) (02/16/85)
> Is there a good reason why an option cannot be added > to ``make'' so that it will directly execute subcommands > such as the compiler, instead of invoking a subshell? Stu Feldman thought it was a good idea - that's why he put it into "make" when he wrote it. The following code comes from "dosys.c", V7/4.2BSD version; the System III and System V versions do the same thing: if(metas(comstring)) status = doshell(comstring,nohalt); else status = doexec(comstring); "doshell" does an "sh -c", and "doexec" chops the command string up itself and does a "fork" and "exec". > The only reason I can think of is to allow shell syntax > such as pipes. "metas()" returns 1 if the string contains any shell meta-characters (like '|' for pipes), and 0 otherwise. > Some tests indicate that a vfork() and execvp() go about twice as > fast as a system(). Not surprising, considering you don't have to fire up "/bin/sh". However, neither version of "make" uses "vfork" - it uses "fork" instead, probably because the child fiddles with various things before execing. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
chris@umcp-cs.UUCP (Chris Torek) (02/19/85)
> Is there a good reason why an option cannot be added > to ``make'' so that it will directly execute subcommands > such as the compiler, instead of invoking a subshell? You could always make a system() routine that scanned its argument for shell metacharacters, and if none were found, invoked programs directly. [Begin silliness] Gee, you could even build in file name pattern matching, pipes, hey even backquote, and... f we put enough work in it, the shell itself becomes: main () { while(fgets(input, sizeof input, sdtin) != NULL) system(buf); exit (0); } ! -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland