IIRC GNU's /bin/true also has massive performance advantage. I am not able to find it presently, but an old post tried to reverse engineer it, and turns out it does caching and whatnot to get something like 12 GBps throughput.

Edit: I was wrong, it is actually GNU 'yes': https://www.teddit.net/r/unix/comments/6gxduc/how_is_gnu_yes...

And yet you might still be right: If an empty file gets parsed and executed by the shell[1], the shell's initialization code might make things much slower than a small C program.

[1] Which is a valid assumption, as it's often the default (not sure if it's POSIX[2]), e.g. this gets clearly executed by my shell despite not having a shebang or anything else:

    echo 'echo $SHELL' > /tmp/foo; chmod +x /tmp/foo; /tmp/foo

[2] Edit: It is POSIX, I know now because there's a whole subthread about it further down, that even quotes the standard, thanks gnarula.

The real reason why things are fast in popular shells is because they implement most of coreutils as builtins. The /bin/true being empty file would prevent it from working when called with exec for example, so that's why we don't use empty files anymore.

I was going to see what strace does with an empty /tmp/foo, and it fails:

> write(2, "strace: exec: Exec format error\n", 32strace: exec: Exec format error

So the empty file is not exec()able. I think it can only be invoked from a shell.

subprocess.call("/tmp/foo", shell=xxxx) demonstrates it.

I wonder if that was the case for Unix v7 that had it zero length? (...mentioned in another thread.)

From quick scan of v7 exec() implementation it seems that it has to be case as getxfile() would return ENOEXEC for files smaller than sizeof(u_exdata) (which is a.out header as C struct).