Hacker News Reader

Comment by yakubin | Hacker News Reader

> Does this mean the smallest /bin/true is actually an empty file?

That was exactly the implementation of /bin/true in Unix v7: <https://github.com/v7unix/v7unix/blob/master/v7/bin/true>

View on HN

And it's actually pretty clever from a performance point-of-view.

You always have to read the inode to determine whether the file is executable. The inode included the locations of the first "direct" blocks of the file's contents. So if the file is empty you know that immediately.

If the file even had a single comment line, it would mean having to do a disk seek to read it. So it would effectively double the disk I/O needed to run "/bin/true"

Clever yes, but you'll get much bigger benefits if you use a filesystem that can store tiny files inside the inode.

It’s also the smallest quine, a program that outputs its own source code.

And probably the one with the single highest number of programming languages for which it is a valid quine[1].

You appear to be missing the link, I would quite like to read it however if you get the chance to edit that in!

It doesn’t actually support what I said I think, but you might like it anyway: http://www.madore.org/~david/computers/quine.html

This is worth its own post on HN

https://news.ycombinator.com/item?id=29888887

He's not missing the link. The link is the empty string.

This subject has been posted about a few times on HN, along with some looks at the evolution of the implementation of the command: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Here's the most recent, with the most comments: https://news.ycombinator.com/item?id=28257666

Meanwhile GNU coreutils version of /bin/true ... https://github.com/coreutils/coreutils/blob/master/src/true....

Fair, though most of that is the fact that it has --help output and also that the same source covers both true and false. But yeah.

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).

A more interesting question: Is it copyrightable?

I'd say it isn't (and the same goes for false); but whether it's patentable is more debatable.

AT&T and Sun seemed to think so https://sudonull.com/post/143079-Copyright-on-the-bin-true-c...

It also means that the shortest quine is an empty file.

Reply on news.ycombinator.com