Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!hao!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix
Subject: Re: commands within ``make''
Message-ID: <493@rlgvax.UUCP>
Date: Sat, 16-Feb-85 15:29:40 EST
Article-I.D.: rlgvax.493
Posted: Sat Feb 16 15:29:40 1985
Date-Received: Mon, 18-Feb-85 08:45:27 EST
References: <583@mako.UUCP>
Distribution: net
Organization: CCI Office Systems Group, Reston, VA
Lines: 30

> 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