@robpike true used to be an empty file
/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
% file true
% echo $?
Is there a reason why it can't return back to that way?
the goons who maintain GNU would never do it.
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.
Leave this field blank: