[net.unix] commands within ``make''

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