Hacker News Reader

Comment by aidenn0 | Hacker News Reader

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

View on HN

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.

https://stackoverflow.com/questions/25165808

Reply on news.ycombinator.com