Re: shortcut of ":" but not /bin/true

[David Boyce]

Paul,

At 05:20 PM 5/17/2004, Paul D. Smith wrote:
> %% David Boyce <address@hidden> writes:
>
>   db> Just wondering why GNU make (apparently) has logic built in to
>   db> skip creating a new process for the ":" shell builtin but not for
>   db> the "true" and "false" commands.
>   db> Is this just an accident of history or is there a reason why it's
>   db> ok to shortcut ":" but not "true"?
>
> I wasn't around when the decision was made, but I think there is a
> reason.
>
> The thinking is (I suspect) that ":" is a shell builtin, and there's
> nothing else it could possibly be.  That is, if you're running a Bourne
> shell (and GNU make does check for this--if you're not, it never chooses
> the "fast path" in the first place) and you see ":" alone as the command
> to run, you always know what it is.

I suspected as much myself. Of course it's a little muddier than that; 
true/false are builtins in /bin/sh on Linux and some others. And I don't 
happen to have a machine around running the original Bourne shell but I 
myself remember when the "if [ foo -eq bar ]" construct was implemented via 
a program called "/bin/[" (back when a shell was a SHELL), so it's not 
entirely clear to me that ":" has always been a builtin.

> With "true" and "false" that's not the case: typically (and certainly in 
> POSIX sh) these are not shell builtins

Is this what you meant to say? I think "and certainly in the classic Bourne 
shell" would be true but /usr/xpg4/bin/sh on Solaris 9, which is as POSIX 
as a POSIX shell can be, implements true and false as builtins. I don't 
believe POSIX says anything about this directly; it mandates that there be 
actual programs called "true" and "false" (it even mandates a standalone 
"cd" command) but does not say that the POSIX shell must *use* those 
programs (and a good thing too in the case of cd).

But your larger point, that the program found at /bin/sh may not always 
implement true/false as builtins, is inarguable.

> so it's possible that there are
> some other programs named "true" or "false" that will be found on your
> PATH before any standard system versions, that will behave differently
> than traditional true and false.

Of course the anal side (or should that be the anal end?) of me wants to 
point out that any such system/configuration would not be POSIX and so 
wouldn't need to be supported at least in .POSIX mode. That said, I 
understand that (a) there are more important things to deal with in make 
and (b) these interfaces are not to be changed lightly. But THAT said, I 
also think this simple change could speed up quite a few builds by a 
measurable margin though of course - having just noticed it this afternoon 
- I have no hard data.

Actually, let me try to dig up a bit of hard data. Since in most cases 
/bin/true is in fact a shell script, actually running it means starting a 
shell to run yet another shell. Here's a clip from trussing the Perl build:

27632:  execve("/bin/sh", 0x00061A80, 0x000618E0)  argc = 3
27632:   argv: /bin/sh -c true
27634:  execve("/usr/bin/true", 0x0003A944, 0x0003AA44)  argc = 2
27634:   argv: /usr/bin/sh /usr/bin/true

which in this build is repeated 561 times for a total of 1122 shell starts. 
I wrote a standalone script to run /bin/true 561 times; it accounts for 
about 1% of the time it takes to build Perl here.

I suppose a compromise position might be to shortcut "/bin/true" and 
"/usr/bin/true" but not "true". But anyway, I have an easy workaround for 
the problem I care about right now. So if you want me to file something let 
me know. If you're content to leave it as is, I'll let it drop.

-David Boyce