Doesn't the 0 byte executable involve spawning a shell to run it? Better would be a tiny elf executable that just returns 0 (maybe hand written to avoid the compiler adding bloat)

No it does not. The 0 byte executable involves first trying to execl() it, the OS returning ENOEXEC, and then spawning a shell.

Of course "spawning a shell" can be very cheap, as you are already in a shell, it's just fork() plus some initialization code (compared to fork() plus exec() for running a non-shell program)

Note that shells must try to interpret at least any text file for which the system returns ENOEXEC [1]

1: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3... Read subsection 1.e.i.b

Oh it is not nearly as good as I thought then. I actually tested it and zero byte exec still make exec() returns ENOEXEC on Linux. So a small binary is definitively more versatile...

Does any shell implement exec of a script as fork and reinit?

Probably Inferno, considering that it also runs proper binaries that way.

Does this mean that putting #!/bin/sh at the head of scripts actually slows them down (assuming you are running from an sh like shell)?

I suggest measuring; there's overhead to the failed exec() call certainly. It probably depends on a lot of other factors too (which, if any rc files are read in each mode, how fast your shell is to startup &c.).

I just tested this.

Files:

1.sh:

    true

2.sh:

    #!/bin/bash
    true

test1.sh:

    for i in `seq 10000`
    do
    ./1.sh
    done

test2.sh:

    for i in `seq 10000`
    do
    ./2.sh
    done

Times for test1.sh:

    11.484s
    11.590s
    11.405s

Times for test2.sh:

    14.273s
    14.391s
    13.847s

So including the #! adds about 23% to the overhead of calling a shell script. Tested on Mint 19.1, bash.

EDIT: for reference, sourcing the scripts instead takes an average of 0.0842s for test1 and 0897s for test2. (and all test2 trials were still slower than all test1 trials), which isn't particuarly suprising.

Inlining true takes about 0.029s

Why did you use bash and not sh for the interpreter?

To keep the comparison fair. My interactive shell is bash (which I assume is a more popular choice for interactive shell then sh), and the version without any shebang will use whatever the parent shell is. To make the comparison fair, I wanted the version with the shebang to be using the same shell.

Besides, /bin/sh would also require dereferencing a symlink (to /bin/dash), which also doesn't seem fair.

Correct. true being a 0 byte shell script is a good example of classic Unix's bad habit of doing the overly-cute thing instead of the sensible thing.

It would be a valid approach but it is less elegant and harder to maintain. Probably the kernel could special case 0 bytes executables, if you really want to optimize the scripted truth.

Special casing 0-byte executables is not necessarily the best solution, either. It's a special case after all, and one that's essentially only there to support /bin/true. This may create security gotchas or inadvertent bugs resulting from the "codeless" address space that gets created (or not created if you implement it that way, with its own set of potential gotchas). I'm not saying it necessarily does create problems, but it can.

And it would actually change the historical and current behavior of exec returning ENOEXEC for 0 bytes executables (see also https://news.ycombinator.com/item?id=19081124 ) . So I am changing my mind: a binary true is better. I still prefer truths as small as possible, though :)

It can be an extra-special 0-byte executable though, running far faster than anything else, like so:

/proc/bin/true

/proc/bin/false

The exec doesn't even need to create page tables or run any non-kernel code. This is a benchmark-winning design.

If you want maintainable, you should just compile "return 0" with your standard toolchain. A 0 byte file risks confusing developers who might see it and think their install is corrupted (surely the program just got truncated). If you want to use an empty program, the maintainable solution would be to comment it; but then it is not empty.