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