3 ms·

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

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_so_fast/?st=j3v3iw3c&sh=5651ea3c https://www.teddit.net/r/unix/comments/6gxduc/how_is_gnu_yes...

anyfoo 5y ago
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.
- Cloudef 5y ago
  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.
- rrauenza 5y ago
  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.)
  - dfox 5y ago
    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).

anyfoo 5y ago

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.

Cloudef 5y ago
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.
rrauenza 5y ago
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.)
- dfox 5y ago
  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).