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. >I think make's optimization of executing certain commands directly >instead of passing them to sh should be rather invisible to the user, >particularly if the optimization may be activated or deactivated by >something seemingly innocuous like toggling -j. Changing the way the dependency graph is processed is probably more often the cause of surprises. But yes, makefiles which need work for -j (heck even separate objdirs) are common enough. >It seems not entirely possible to hide the optimization completely as >that would require deeper knowledge of the shell in make. Shell builtins >are usually found before a PATH search and there may be non-standard >shell builtins. True, which is a good argument for having a standard shell as part of the build environment. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
