@robpike true used to be an empty file

1 Name: Anonymous 2018-02-23 13:35
/bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code.
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.
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.
(It probably became a shell builtin somewhere along the line too, but that's for someone else to study.)
The command moved to /usr/bin/true. I don't know when, where and especially why.
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.
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.
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 $?
2 Name: Anonymous 2018-02-28 10:55
Is there a reason why it can't return back to that way?
3 Name: Anonymous 2018-02-28 13:25
the goons who maintain GNU would never do it.
4 Name: Anonymous 2018-02-28 22:49
If the GNU maintainers don't care, I probably wouldn't care either; it's not as if I'm maintaining it. I also cannot forecast any meaningful exploit from GNU true being a C program rather than a literal blank file. In the end, this is a matter of aesthetics. The GNU way has never been the way of aesthetically pleasing code.
5 Name: Anonymous 2018-05-17 02:47
Lisp machines already solved this problem. Lisp has a GC, so there's one GC for everything. Hash tables, bignums, rationals, objects, classes, structures, arrays, strings, packages, and functions are all standard data types that can be shared between any program and created at runtime. Strings have all the properties you expect like being able to grow and shrink to fit the size of the text, and on the Symbolics machines they even had font attributes. Arrays support multiple dimensions with displacement like a rectangular part of a window. Everything on a Lisp machine also has built-in bounds checking and data is promoted to larger types if necessary. All of this is done by a combination of hardware, microcode, and OS, so programs don't need nearly as much code.

Maybe it was on someone's calendar to fix, but they
never see it because they can't run the program either.

Hmm. I used to think the strength of lisp machine tools
came from the fact that the developers actually used them
regularly in their work and depended on them in order to
develop everything they were going to need in the next
generation system. That is, I though that there was a
causal link between using your own tools and making them

But maybe it's not whether you use your own tools that
makes them good, but rather that the goodness or badness of
your tools is just magnified over time by continuing to use
them. That would explain a lot of things about Unix...
6 Name: Anonymous 2018-05-17 04:14
Who gives a shit the creator of Go thinks?
7 Name: Anonymous 2018-05-21 07:07
I'd be more surprised if he didn't.
8 Name: Anonymous 2018-05-26 05:02
"Eunuch" operating systems are harmful, bring back Lithp machines.
9 Name: Anonymous 2018-05-26 10:15
lithp my dif

Leave this field blank: