Date: Wed, 22 Aug 2012 17:36:03 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org>, "David E. O'Brien" <obrien@FreeBSD.org> Subject: Re: svn commit: r238563 - head/gnu/usr.bin/groff/tmac Message-ID: <20120823003603.9B58458088@chaos.jnpr.net> In-Reply-To: <20120822223002.GA41104@stack.nl> References: <201207180557.q6I5vheM034018@svn.freebsd.org> <20120726084903.GA48240@lo0.su> <20120821053519.BD5A158085@chaos.jnpr.net> <20120821222943.GA27203@stack.nl> <20120821232553.35D4F58085@chaos.jnpr.net> <20120822223002.GA41104@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120823003603.9B58458088>