Quoth Manoj Srivastava <[email protected]>, on 2009-12-24 16:35:49 -0600:
> So, a POSIX shell will be called -- or make shall pretend that a
> POSIX shell is called with the command line.
[...]
> > ----------------------------------------
> > $ make -f ~/tmp/type.mk
> > type ls
> > make: type: Command not found
> > make: *** [all] Error 127
> > ----------------------------------------
>
> This is because type is part of the X/Open Systems Interfaces
> option, but not a builtin part of POSIX itself. Nothing states that the
> POSIX shell invoked by Make supports the XSI option.
First of all, thank you for paying attention. :-)
Your point is sound. I originally assumed that the shell should be
the same one invoked by "sh" (in this case, /bin/sh, which is dash on
my system, and does support the XSI extension "type") unless specified
otherwise, but you are correct in that nothing seems to say that the
"sh" used by system(3) and the "sh" invoked from the command line must
be the same.
I do note that system("type ls") does execve("/bin/sh", ...), so in
this case the behavior of make doesn't correspond to the behavior of
system(3). I'm not sure what implications that has, if any. I also
note that the GNU Make documentation (in section 1, "Overview of
`make'") actually refers to 1003.2-_1992_, which is interesting; I
haven't looked at the differences yet.
Anyway, the flip side of this is whether it corresponds to the GNU
Make documentation, which I also examined when I first encountered
this behavior, to see whether it was mentioned anywhere. (The
behavior is the same whether I include the .POSIX declaration or not.)
Examining it again, I find the following:
>From the manual for GNU Make 3.81, section 5.3.1 "Choosing the Shell":
| The program used as the shell is taken from the variable `SHELL'.
| If this variable is not set in your makefile, the program `/bin/sh'
| is used as the shell.
>From section 5.3 "Command Execution":
| When it is time to execute commands to update a target, they are
| executed by invoking a new subshell for each command line. (In
| practice, `make' may take shortcuts that do not affect the results.)
... but in fact, this shortcut does affect the results as compared
specifically to using a /bin/sh subshell on this system. The GNU Make
documentation appears to make stronger claims than POSIX in this case.
Of course, the set of extensions available for the shell in use is not
really predictable by GNU Make, so strictly following that would make
the shortcuts nearly impossible to use, and I assume there is a good
reason for them if the effort was made to put them in in the first
place. I notice that when I set SHELL to /bin/sh explicitly in the
Makefile, the behavior stays the same, but when I set it to something
else, such as /bin/dash or /bin/bash, the shortcuts are turned off.
If the current behavior is considered correct, possibly the manual
should mention that it will assume only certain builtins need to be
passed to /bin/sh, and/or how to explicitly turn this mechanism off in
the case where one wants to use /bin/sh but under the assumption that
it will have certain extra properties (which would be a portability
constraint imposed by the Makefile writer, but not IMHO something GNU
Make should itself exclude).
I would also respectfully request that unless this is Debian-specific
behavior, this report be demoted to wishlist status but remain open
until GNU Make upstream decides on it. (That probably implies
forwarding; I will forward the report myself if requested.)
> manoj
---> Drake Wilson
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
