On Wed, Aug 22, 2012 at 05:36:03PM -0700, Simon J. Gerraty wrote: > > On Thu, 23 Aug 2012 00:30:02 +0200, Jilles Tjoelker writes: > >I think the most important reason is to reduce special cases. The POSIX > >developers did not want to create a second subset of utilities that are > >not available via execve() (the first subset is the special builtins). > >The burden on implementations is very low (see src/usr.bin/alias), and > >there are some possible use cases:
> The burden may be low, but so is the functionality ;-) > 'cd' makes little sense in a child process. > >'cd' will fail if the directory does not exist. > so will 'test -d', and without giving the false impression that > something useful will result if the directory does exist. > >If it avoids the need to add semicolons for mysterious reasons, that may > >be enough reason. > I think everyone agrees that re-writing the target to remove the > spurious 'cd' would have been better. > That aside, I would disagree, at least for the case of 'cd'. > It is only the fact that there is probably no way to construct a harmful > example that did not involve a shell meta char (hence rendering the > existance of /usr/bin/cd irrelevant). 'cd /tmp/dir && rm -rf *' > would be rather dangerous if the && (or ;) didn't trigger use of a > shell, and since as previously noted just 'cd /tmp/dir' is pretty > pointless, the functionality is very low. > In over 25 years of writing makefiles, I don't recall seeing this before. OK, but then you should document the conditions when shell builtins are or are not allowed. POSIX make command lines are executed as if by the shell, and if the make implementation wants to optimize by not executing sh for every command line, the burden is on it to make it behave the same. The bmake (NetBSD make) man page gives the same impression. It does not mention the optimization of bypassing the shell at all. The FreeBSD make man page mentions the optimization implicitly when it describes the meta and builtins keys of the .SHELL special target but still gives the impression that these are correct (which they mostly are, but not entirely). -- Jilles Tjoelker _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
