On Fri, Apr 15, 2011 at 09:07:09PM +0800, Herbert Xu wrote: > On Sun, Apr 10, 2011 at 07:18:17AM +0000, Jonathan Nieder wrote: > > Jilles Tjoelker wrote[0]: > > > Regarding sh -c optimization, I am in favour of this. Uselessly waiting > > > 'sh -c' processes annoy me. I made the change for FreeBSD 8.0 sh, which > > > is very similar to dash. The SVN changeset is r194128. > > So I grabbed that changeset with > > svn log -v svn://svn.freebsd.org/base/head/bin/sh -r 194128 > > svn diff -r 194127:194128 svn://svn.freebsd.org/base/head/bin/sh > > and made it a tiny bit smaller. Here's the result. > > text data bss dec hex filename > > 83994 1784 11128 96906 17a8a dash.before-O2 > > 83994 1784 11128 96906 17a8a dash.before-Os > > 84146 1784 11128 97058 17b22 dash.after-O2 > > 84146 1784 11128 97058 17b22 dash.after-Os > > On this amd64 the cost is 152 bytes of text. Thoughts? > I must say that I don't see much value in this feature. Adding > exec to the invocation is trivial. It is trivial when writing command lines that are obviously going to be passed to sh -c, but in practice it is often not done. The optimization would be useful with system(), popen() and Makefiles; rarely does one see an "exec" in such contexts. In a Makefile, "exec" can be actively detrimental since it usually forces the command to be run using the shell, preventing a direct execve() by make. In all contexts, "exec" is detrimental if a builtin version of the executed utility exists. If the utility is a special builtin, prepending "exec" is very likely to cause the command to stop working, and otherwise it adds a useless execve(). It was proposed to add text encouraging "exec" prepending to POSIX, but this was rejected. See http://austingroupbugs.net/view.php?id=236 and http://thread.gmane.org/gmane.comp.standards.posix.austin.general/1918 . -- Jilles Tjoelker -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html