3 ms·
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
by 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 agoThe 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 agoI 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 agoFrom 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).