Your message dated Thu, 24 Dec 2009 16:35:49 -0600 with message-id <[email protected]> and subject line Re: Bug#562491: make: shell-skipping heuristics fail to take some builtins into account has caused the Debian Bug report #562491, regarding make: shell-skipping heuristics fail to take some builtins into account to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 562491: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562491 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: make Version: 3.81-7 Severity: normal I'm not sure whether this qualifies as normal or wishlist; it depends on how much GNU Make cares about POSIX compatibility. In this message, I primarily reference POSIX:2001. POSIX says, regarding make(1): | Command execution shall be as if the makefile command line were the | argument to the system() function. Regarding system(3): | The environment of the executed command shall be as if a child process | were created using fork(), and the child process invoked the sh | utility using execl() as follows: | | execl(<shell path>, "sh", "-c", command, (char *)0); | | where <shell path> is an unspecified pathname for the sh utility. sh -c has no special rules for builtins as opposed to other commands. I interpret this to mean that a command in a Makefile is allowed to contain a single shell builtin invocation, and that this should invoke the builtin. Creating a file "type.mk" with the contents: ---------------------------------------- .POSIX: all: type ls ---------------------------------------- (with the first character on line 3 being a tab) results in: ---------------------------------------- $ make -f ~/tmp/type.mk type ls make: type: Command not found make: *** [all] Error 127 ---------------------------------------- Adding any shell metacharacters causes the shell to be invoked, and then the "type" command succeeds properly. Many builtins also have associated executables, but this is not required for all builtins. What to do about this is unclear. I don't see any way to turn off the heuristic other than by working around it with useless metacharacter-y clauses in the Makefile. Possibly detecting the .POSIX target and turning it off then would be suitable, or possibly giving the shell a second try iff a command is not found directly for exec(3) purposes, though the latter still changes the priority between executables and shell builtins. ---> Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages make depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries make recommends no packages. Versions of packages make suggests: ii make-doc 3.81-5 Documentation for the GNU version -- no debconf information
--- End Message ---
--- Begin Message ---On Thu, Dec 24 2009, Drake Wilson wrote: > I'm not sure whether this qualifies as normal or wishlist; it depends > on how much GNU Make cares about POSIX compatibility. In this > message, I primarily reference POSIX:2001. My take on it is that this is not a bug. I use IEEE Std 1003.1™-2008. > POSIX says, regarding make(1): > | Command execution shall be as if the makefile command line were the > | argument to the system() function. > > Regarding system(3): > | The environment of the executed command shall be as if a child process > | were created using fork(), and the child process invoked the sh > | utility using execl() as follows: > | > | execl(<shell path>, "sh", "-c", command, (char *)0); > | > | where <shell path> is an unspecified pathname for the sh utility. So, a POSIX shell will be called -- or make shall pretend that a POSIX shell is called with the command line. > > sh -c has no special rules for builtins as opposed to other commands. > I interpret this to mean that a command in a Makefile is allowed to > contain a single shell builtin invocation, and that this should invoke > the builtin. OK > > Creating a file "type.mk" with the contents: > > ---------------------------------------- > .POSIX: > all: > type ls > ---------------------------------------- > > (with the first character on line 3 being a tab) results in: > > ---------------------------------------- > $ 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. > Adding any shell metacharacters causes the shell to be invoked, and > then the "type" command succeeds properly. Many builtins also have > associated executables, but this is not required for all builtins. Right. The external shell that is invoked, in your case, just happens to support the XSI option. In other words, you got lucky. > What to do about this is unclear. I don't see any way to turn off the > heuristic other than by working around it with useless metacharacter-y > clauses in the Makefile. Possibly detecting the .POSIX target and > turning it off then would be suitable, or possibly giving the shell a > second try iff a command is not found directly for exec(3) purposes, > though the latter still changes the priority between executables and > shell builtins. I think that one can't actually portably rely on XSI extensions. manoj -- "God does not care about our mathematical difficulties. He integrates empirically." Albert Einstein Quotes On Math and Science and Education Manoj Srivastava <[email protected]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--- End Message ---
