/bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code.
-
Show this thread
-
When the Unix Support Group (development organization at Bell Labs) formalized everything, they gave it a long SCCS header, as they did every other file, and then needed to add "exit 0" at the end. The file was therefore infinitely larger than before.
3 replies 13 retweets 146 likesShow this thread -
At some point, somewhere (not sure where) it was decided this was poor engineering, probably because the shell spends time reading that big SCCS header as a comment one byte at a time.
1 reply 5 retweets 97 likesShow this thread -
(It probably became a shell builtin somewhere along the line too, but that's for someone else to study.)
3 replies 3 retweets 84 likesShow this thread -
The command moved to /usr/bin/true. I don't know when, where and especially why.
3 replies 7 retweets 92 likesShow this thread -
Eventually to avoid the unbearable overhead of executing a comment that shouldn't be there at all, someone rewrote true as a C program. What was once an empty file is now a non-portable executable binary compiled from C.
4 replies 33 retweets 198 likesShow this thread -
This is why we can't have good software. This program could literally have been an empty file, a nothing at all, a name capturing the essence perfectly.
5 replies 67 retweets 399 likesShow this thread -
But the inexorable forces of improvement dictate we can't accept that, so here we are: % file /usr/bin/true /usr/bin/true: Mach-O 64-bit executable x86_64 % Instead of: % file true true: empty % true % echo $? 0 %
28 replies 78 retweets 431 likesShow this thread
The real story here is that SCCS is evil.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.