[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Boyce
Subject: Re: shortcut of ":" but not /bin/true
Date: Mon, 17 May 2004 19:51:00 -0400


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]