Handling of shell builtins in make(1)

Harti Brandt hartmut.brandt at dlr.de
Tue May 24 03:46:37 PDT 2005


On Tue, 24 May 2005, Peter Jeremy wrote:

PJ>On Mon, 2005-May-23 20:50:40 -0600, Scott Long wrote:
PJ>>Harti Brandt wrote:
PJ>>>The result of this is that for one and the same command you can get 
PJ>>>different behaviour whether you execute it via make(1) or via sh -c '...'.
PJ>
PJ>Not to mention the effect of IFS.  Does POSIX provide any helpful
PJ>suggestions on how to efficiently implement the behaviour they specify?

POSIX has no .SHELL target - that's pmake's invention. IFS is no problem 
because in order to specify a different IFS you need to have at least a 
'=' on the command line. This is a meta character so the command will be 
executed by the shell.

Generally POSIX says that make should execute command lines as if given to 
system(). System() in turn says that it should behave as if it fork()ed 
and execl()ed "sh -c ...". The as-if here seems to allow for our 
optimisation.

 PJ>
PJ>>4. Separate /bin/sh into a front end and back end (libsh) and include 
PJ>>libsh into make.
PJ>
PJ>And this still won't help people who use .SHELL (or similar) to pick
PJ>a different shell.
PJ>
PJ>5) Add a "POSIX_ME_HARDER" option that just invokes the shell on every
PJ>   command.  In the absence of this option, make(1) is free to directly
PJ>   exec the command if it's simple enough.
PJ>
PJ>6) Add two new magic line markers (to supplement '@', '+' and '-') to
PJ>   require the line be executed using the shell or exec'd directly,
PJ>   superceding the buildin rules.

You can alway make to execute the shell by putting a meta-character on the 
command line or by specifying and empty builtin list or an empty meta 
character list to .SHELL. But what should we do as default?

harti


More information about the freebsd-arch mailing list