True

true is the one true program. It is perfection. It does nothing, yet is successful. It never fails. It returns the status code zero. It will always be there for you. It can always be trusted. It is true.

/true/ user group thread

Attached: true.png (324x273, 7K)

Other urls found in this thread:

github.com/coreutils/coreutils/blob/master/src/true.c
twitter.com/AnonBabble

sjw's will argue about this

>do nothing
>be successful

the dream

/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 $?
0
%


-- rob

$ ldd /bin/true
linux-vdso.so.1 (0x00007ffd7551b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff165bc5000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1661be000)

why does /bin/true need to dynamically link libc again?

because something stupid
github.com/coreutils/coreutils/blob/master/src/true.c

Welcome to the true man's world.

oh right... because it needs to tell you about GPL license

~> true derp
true: expected 0 args, got 1
~> echo $status
121

>probably became a shell builtin
And at this point everyone stopped caring

>80 lines just to return true

>perfect
>requiring file access

to be fair, plan9ers didn't care much about file access as they replaced most IPC and syscalls with it

and without file access, it would have to be either frankensteined shell with builtins for optimizations, or OO system (such as lisp machines, which would be perfect)

Attached: large.jpg (250x250, 54K)

can someone explain status codes
why 0 success and not 1

I like yes more.

>CompSci first years be like

the mnemonics would be to ask "was there an error?"
0 => False=>there was no error
non-0 => True => there was an error

but afaik there are no conventions for what error codes you should return e.g. for file not found etc.

That way you can return the error code.
There can be many ways in which a program can fail, but only one in which it succeeds.
0 just means "no error code".

big if true

>but afaik there are no conventions for what error codes you should return e.g. for file not found etc.
errno error codes like ENOENT for your example seem reasonable.

That's why it's called an error code. If it was a boolean, it would be `error = false` or `error = true`. Thus `error = 0` means no error.

but the convention is to
err(1, "fn that triggered error")

(or non-panic variant) to actually display errno message and reason, but return 1. Do idk.

int
main (int argc, char **argv)
{

Absolutely disgusting

that's very common in non-GNU world as well, pretty much unix-style standard

>getting hung up on trivial semantics

Have you ever worked in a team with other people's code? The above doesn't even compare.