From owner-svn-src-head@FreeBSD.ORG Thu Aug 23 00:39:33 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D42CB10656DA; Thu, 23 Aug 2012 00:39:33 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id 311468FC17; Thu, 23 Aug 2012 00:39:32 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUDV7vUTMvzPXEcuG7tNxjN6WgzNXOF8T@postini.com; Wed, 22 Aug 2012 17:39:33 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Aug 2012 17:36:04 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7N0a3h67762; Wed, 22 Aug 2012 17:36:04 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 9B58458088; Wed, 22 Aug 2012 17:36:03 -0700 (PDT) To: Jilles Tjoelker 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> Comments: In-reply-to: Jilles Tjoelker message dated "Thu, 23 Aug 2012 00:30:02 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 22 Aug 2012 17:36:03 -0700 Message-ID: <20120823003603.9B58458088@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Ruslan Ermilov , "David E. O'Brien" Subject: Re: svn commit: r238563 - head/gnu/usr.bin/groff/tmac X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 00:39:34 -0000 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.