Date: Fri, 19 Nov 2010 17:24:29 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r215520 - in head: bin/sh share/man/man1 usr.bin/printf Message-ID: <20101119162429.GD7614@stack.nl> In-Reply-To: <20101119152127.GA29131@FreeBSD.org> References: <201011191256.oAJCuDFH074482@svn.freebsd.org> <20101119152127.GA29131@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 19, 2010 at 03:21:27PM +0000, Alexey Dokuchaev wrote: > On Fri, Nov 19, 2010 at 12:56:13PM +0000, Jilles Tjoelker wrote: > > Side effect: printf is now always the builtin version (which behaves > > identically to /usr/bin/printf) and cannot be overridden via PATH (except > > via the undocumented %builtin mechanism). > Are there any plans to document it? It would have to be fixed first so it has sensible behaviour. Right now all builtins, including ones that must execute as a builtin for full functionality, can be overridden via %builtin, which does not seem to make a lot of sense. POSIX (XCU 2.9.1.1 Command Search and Execution) requires that special builtins and some other builtins such as bg, cd and command be found without a PATH search. For consistency with execvp(3) and perhaps also for POSIX compliance, the special cases with % are not really good. Another way to allow overriding builtins would be to make each overridable builtin pretend to be in a directory (e.g. /usr/bin) and be found at that point in the PATH search. For example, printf could pretend to be /usr/bin/printf, which would mean PATH=/usr/bin printf would find the builtin, but PATH=/elsewhere:/usr/bin printf would find /elsewhere/printf if it exists. Command names containing slashes would not participate in this and always invoke the external program. For example, /usr/bin/printf would continue to use the external program. Some builtins in ksh93 (but not printf) work this way. If the echo builtin pretends to be /bin/echo, it is a bit strange because the two utilities are rather incompatible. If I take POSIX's list and add other utilities that must execute as a builtin for full functionality, only very few utilities remain. Many of these are non-standard and are not present in the filesystem. In the specific case of printf, note that the bash, ksh93 and zsh versions of the printf builtin support %n, writing the result into a specified shell variable, which can only work if it is a builtin. Although our printf does not support this and I do not plan on adding it, it means that various shell authors think printf should always be a builtin. The general issue is that I do not know how exactly %builtin is or can be used in practice. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101119162429.GD7614>