/bin/true (was [TUHS] basic tools / Universal Unix)

/bin/true (was [TUHS] basic tools / Universal Unix)

[Ron Natalie]

My favorite reduction to absurdity was /bin/true.   Someone decided we
needed shell commands for true and false.   Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0.  /bin/true turned into an empty, yet executable, file.

Then the lawyers got involved.    We got a version of a packaged UNIX (I
think it was Interactive Systems).    Every shell script got twelve lines of
copyright/license boilerplate.     Including /bin true.
The file had nothing but useless comment in it.

/bin/true (was [TUHS] basic tools / Universal Unix)

[Pete Wright]

On 10/19/2017 07:52, Ron Natalie wrote:
> My favorite reduction to absurdity was /bin/true.   Someone decided we
> needed shell commands for true and false.   Easy enough to add a script that
> said "exit 0" or exit 1" as its only line.
> Then someone realized that the "exit 0" in /bin true was superfluous, the
> default return was 0.  /bin/true turned into an empty, yet executable, file.
>
> Then the lawyers got involved.    We got a version of a packaged UNIX (I
> think it was Interactive Systems).    Every shell script got twelve lines of
> copyright/license boilerplate.     Including /bin true.
> The file had nothing but useless comment in it.

heh yea it certainly seems pretty funny, but i will say it did present a 
neat opportunity for the NYC BSD user-group back in 2015:
http://www.nycbug.org/index.cgi?action=view&id=10635

it was pretty funny to see how many different implementations one could 
dream up for such a simple program, and it seemed to speak to how each 
project approaches complexity.

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA

/bin/true (was [TUHS] basic tools / Universal Unix)

[Chet Ramey]

On 10/19/17 11:01 AM, Pete Wright wrote:

> heh yea it certainly seems pretty funny, but i will say it did present a
> neat opportunity for the NYC BSD user-group back in 2015:
> http://www.nycbug.org/index.cgi?action=view&id=10635
> 
> it was pretty funny to see how many different implementations one could
> dream up for such a simple program, and it seemed to speak to how each
> project approaches complexity.

It's a nitpick, but I notice they didn't use the actual bash code that
implements this, but rather an example template for a loadable shell
builtin.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

/bin/true (was [TUHS] basic tools / Universal Unix)

[Steffen Nurpmeso]

Mr. Ron Natalie,

"Ron Natalie" <ron at ronnatalie.com> wrote:
 |My favorite reduction to absurdity was /bin/true.   Someone decided we
 |needed shell commands for true and false.   Easy enough to add a script that
 |said "exit 0" or exit 1" as its only line.
 |Then someone realized that the "exit 0" in /bin true was superfluous, the
 |default return was 0.  /bin/true turned into an empty, yet executable, file.

i am actively chewing on this.
These things can be found by the exec family of C functions,
as Chet Ramey points out from time to time (but i think on other
lists).  That even makes things which make no sense but as
a shell builtin a little bit understandable... maybe..
I for one am ever so fascinated of Unix!
I cannot remember what i thought once entering the Unix world,
i remember i first did not understand why and that [ etc. do exist.

 |Then the lawyers got involved.    We got a version of a packaged UNIX (I
 |think it was Interactive Systems).    Every shell script got twelve lines of
 |copyright/license boilerplate.     Including /bin true.
 |The file had nothing but useless comment in it.

Yes.  But then nonetheless quite the opposite, it was very strange
looking at Plan9 source code which does not have such a file
header, after living in the world of BSD and GNU source code for
one and a half decade.  Different to your experience, for me the
lawyers were there first.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

/bin/true (was [TUHS] basic tools / Universal Unix)

[Dave Horsfall]

On Thu, 19 Oct 2017, Ron Natalie wrote:

> My favorite reduction to absurdity was /bin/true.  Someone decided we 
> needed shell commands for true and false.  Easy enough to add a script 
> that said "exit 0" or exit 1" as its only line. Then someone realized 
> that the "exit 0" in /bin true was superfluous, the default return was 
> 0.  /bin/true turned into an empty, yet executable, file.
>
> Then the lawyers got involved.  We got a version of a packaged UNIX (I 
> think it was Interactive Systems).  Every shell script got twelve lines 
> of copyright/license boilerplate.  Including /bin true. The file had 
> nothing but useless comment in it.

I've also seen /bin/true and /bin/false (I've often been tempted to write 
"/bin/maybe" to introduce a little non-determinism) as *separate binaries* 
i.e. not even linked.

These days they appear to be built-ins (as I would expect).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

/bin/true (was [TUHS] basic tools / Universal Unix)

[Chet Ramey]

On 10/19/17 5:23 PM, Steffen Nurpmeso wrote:

> These things can be found by the exec family of C functions,
> as Chet Ramey points out from time to time (but i think on other
> lists).  

Yes, Posix requires that all builtins be execable. It doesn't require
true and false to be implemented as builtins, though.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

/bin/true (was [TUHS] basic tools / Universal Unix)

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

> 
> I've also seen /bin/true and /bin/false (I've often been tempted to write "/bin/maybe" to introduce a little non-determinism) as *separate binaries* i.e. not even linked.
> 

/bin/maybe goes well with the motd that says “You might have mail.”     I told one of my student programmers that he could put that in the motd and I guaranteed that within an hour someone would come in and tell me that he checked and he didn’t have mail.    Sure enough one of my senior programmers came in and said “It said I might have mail and I didn’t have any.”    I pointed out it only said “might.”

[TUHS] /bin/true (was basic tools / Universal Unix)

[Dave Horsfall]

On Thu, 19 Oct 2017, Chet Ramey wrote:

> Yes, Posix requires that all builtins be execable. It doesn't require
> true and false to be implemented as builtins, though.

Good luck with "cd"...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] /bin/true (was basic tools / Universal Unix)

[Grant Taylor]

On 10/19/2017 05:00 PM, Dave Horsfall wrote:
> Good luck with "cd"...

There's nothing that states that the executable effectively do anything. 
  ;-)

spawn,
cd to specified directory
exit

}:-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171019/51ecc013/attachment.bin>

[TUHS] /bin/true (was basic tools / Universal Unix)

[Lyndon Nerenberg]

: lyndon at orthanc:/home/lyndon; cat ./cd
#!/bin/sh

builtin cd $1 && /bin/sh -i

[TUHS] /bin/true (was basic tools / Universal Unix)

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, 19 Oct 2017, Ronald Natalie wrote:

> /bin/maybe goes well with the motd that says “You might have mail.” I 
> told one of my student programmers that he could put that in the motd 
> and I guaranteed that within an hour someone would come in and tell me 
> that he checked and he didn’t have mail.  Sure enough one of my senior 
> programmers came in and said “It said I might have mail and I didn’t 
> have any.” I pointed out it only said “might.”

Seriously, it could be used in test scripts, to see whether a test depends
implicitly upon a previous one, so if something fails it would be worthy 
of investigation.

     Usage: maybe [p]

     Returns "true" (0) with a probability of "p" [0.0:1.0] (default: 0.5),
     else "false" (1).

C:	exit(**argv != 't');	// Assumes "t*" or not.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] /bin/true (was basic tools / Universal Unix)

[Kurt H Maier]

On Thu, Oct 19, 2017 at 05:14:49PM -0600, Grant Taylor via TUHS wrote:
> On 10/19/2017 05:00 PM, Dave Horsfall wrote:
> > Good luck with "cd"...
> 
> There's nothing that states that the executable effectively do anything. 

It's still useful.  Minimal example:

[khm at pc ~]$ (exec cd /); echo $?
0
[khm at pc ~]$ (exec cd /nosuchpath); echo $?
/usr/bin/cd: line 2: cd: /nosuchpath: No such file or directory
1

You can use this to dodge some of the crappier shells' problems,
sometimes, or to test for directory accessibility in a clean
environment.  I've run across it in the wild on occasion, even if I
don't really play this sort of game myself.

khm

[TUHS] /bin/true (was basic tools / Universal Unix)

[Dan Cross]

[I tried to send this earlier, but was thwarted by list shenanigans.
Apologies if it's a dup.]

On Thu, Oct 19, 2017 at 10:52 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> My favorite reduction to absurdity was /bin/true.   Someone decided we
> needed shell commands for true and false.   Easy enough to add a script that
> said "exit 0" or exit 1" as its only line.
> Then someone realized that the "exit 0" in /bin true was superfluous, the
> default return was 0.  /bin/true turned into an empty, yet executable, file.
>
> Then the lawyers got involved.    We got a version of a packaged UNIX (I
> think it was Interactive Systems).    Every shell script got twelve lines of
> copyright/license boilerplate.     Including /bin true.
> The file had nothing but useless comment in it.

Gerard Holzmann has something on this that I think is great:

http://spinroot.com/gerard/pdf/Code_Inflation.pdf

        - Dan C.

PS: A couple of thoughts.

The shell script hack on 7th Edition doesn't work if one tries to
'execl("/bin/true", "true", NULL);'.  This is because the behavior of
re-interpreting an execution failure as a request to run a script is
done by the shell, not exec in the kernel. This implies that one could
not directly exec a shell script, but rather must exec the shell and
give the path to the script as the first argument. I vaguely recall we
had a discussion about the origin of the '#!' syntax and how this was
addressed about a year or so ago.

I tried to write a teeny-tiny '/bin/true' on my Mac. Dynamically
linked, the obvious "int main() { return 0; }" is still a little over
4KB. Most of that is zeros; padding for section alignment and the
like. I managed to create a 'statically' linked `true` binary by
writing the program in assembler:

% cat true.s
# /bin/true in x86_64 assembler for Mac OS X
.text
.globl start
start:
mov $0x2000001, %rax # BSD system call #1
mov $0, %rdi # Exit status: 0 = 'true'
syscall

# OS X requires a non-empty data segment.
.data
zero: .word 0 As I recall,
%

macOS requires you to have a data section aligned to 4K, even if you
don't use it. The resulting binary is a little over 8K; again, mostly
zeros.

There are parlor tricks people play to get binary sizes down to
incredibly small values, but I found the results interesting. Building
the obvious C program on a PDP-11 running 7th Edition yields a 136
byte executable, stripped. Still infinitely greater than /bin/true in
the limit, but still svelte by modern standards.

[TUHS] /bin/true (was basic tools / Universal Unix)

[Lyndon Nerenberg]

> On Oct 19, 2017, at 6:27 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> macOS requires you to have a data section aligned to 4K, even if you
> don't use it. The resulting binary is a little over 8K; again, mostly
> zeros.
> 
> There are parlor tricks people play to get binary sizes down to
> incredibly small values, but I found the results interesting. Building
> the obvious C program on a PDP-11 running 7th Edition yields a 136
> byte executable, stripped. Still infinitely greater than /bin/true in
> the limit, but still svelte by modern standards.

No matter how tiny you can make the a.out, the kernel's still going to have to map in at least one page to hold it, so you're eating a minimum of 4K on any modern machine, regardless.

[TUHS] /bin/true (was basic tools / Universal Unix)

[Ronald Natalie]

Of course, 4K is in the noise on a machine with 32 Gig or more of memory.

The old PDP-11 could put a 136 byte executable (assuming the standard UNIX V6 a.out header into two 64 byte chunks of memory.    Not too shabby even in those days.

> On Oct 19, 2017, at 9:31 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> 
>> On Oct 19, 2017, at 6:27 PM, Dan Cross <crossd at gmail.com> wrote:
>> 
>> macOS requires you to have a data section aligned to 4K, even if you
>> don't use it. The resulting binary is a little over 8K; again, mostly
>> zeros.
>> 
>> There are parlor tricks people play to get binary sizes down to
>> incredibly small values, but I found the results interesting. Building
>> the obvious C program on a PDP-11 running 7th Edition yields a 136
>> byte executable, stripped. Still infinitely greater than /bin/true in
>> the limit, but still svelte by modern standards.
> 
> No matter how tiny you can make the a.out, the kernel's still going to have to map in at least one page to hold it, so you're eating a minimum of 4K on any modern machine, regardless.

[TUHS] /bin/true (was basic tools / Universal Unix)

[Chet Ramey]

On 10/19/17 7:00 PM, Dave Horsfall wrote:
> On Thu, 19 Oct 2017, Chet Ramey wrote:
> 
>> Yes, Posix requires that all builtins be execable. It doesn't require
>> true and false to be implemented as builtins, though.
> 
> Good luck with "cd"...

It doesn't have to do what you think it should. Using `cd' with something
like `find' or `env' is a fine way to test directory accessibility. The
Posix standard contains several examples of such use.

http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] /bin/true (was basic tools / Universal Unix)

[Dave Horsfall]

On Thu, 19 Oct 2017, Kurt H Maier wrote:

> It's still useful.  Minimal example:
>
> [khm at pc ~]$ (exec cd /); echo $?
> 0
> [khm at pc ~]$ (exec cd /nosuchpath); echo $?
> /usr/bin/cd: line 2: cd: /nosuchpath: No such file or directory
> 1

And others pointed out the same thing; OK, it's obscure (because "test -x 
{}" doesn't quite fit the bill) but I'm convinced.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] /bin/true (was basic tools / Universal Unix)

[Nemo]

On 19 October 2017 at 10:52, Ron Natalie <ron at ronnatalie.com> wrote:
> My favorite reduction to absurdity was /bin/true.   Someone decided we
> needed shell commands for true and false.   Easy enough to add a script that
> said "exit 0" or exit 1" as its only line.
> Then someone realized that the "exit 0" in /bin true was superfluous, the
> default return was 0.  /bin/true turned into an empty, yet executable, file.
>
> Then the lawyers got involved.    We got a version of a packaged UNIX (I
> think it was Interactive Systems).    Every shell script got twelve lines of
> copyright/license boilerplate.     Including /bin true.
> The file had nothing but useless comment in it.

A late comment:  I seem to recall this boilerplate in earlier Solaris
but Solaris 10 has an executable.  So I looked at the OpenSolaris
source out of curiosity and found this.

[CDDL stuff here]
/*
 * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
 * Use is subject to license terms.
 */

#pragma ident   "%Z%%M% %I%     %E% SMI"

#include <unistd.h>

/*
 * Exit with a zero value as quickly as possible.
 */

int
main(void)
{
        _exit(0);
        /*NOTREACHED*/
        return (0);
}

N.

[TUHS] /bin/true (was basic tools / Universal Unix)

[Warner Losh]

On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224 at gmail.com> wrote:

> On 19 October 2017 at 10:52, Ron Natalie <ron at ronnatalie.com> wrote:
> > My favorite reduction to absurdity was /bin/true.   Someone decided we
> > needed shell commands for true and false.   Easy enough to add a script
> that
> > said "exit 0" or exit 1" as its only line.
> > Then someone realized that the "exit 0" in /bin true was superfluous, the
> > default return was 0.  /bin/true turned into an empty, yet executable,
> file.
> >
> > Then the lawyers got involved.    We got a version of a packaged UNIX (I
> > think it was Interactive Systems).    Every shell script got twelve
> lines of
> > copyright/license boilerplate.     Including /bin true.
> > The file had nothing but useless comment in it.
>
> A late comment:  I seem to recall this boilerplate in earlier Solaris
> but Solaris 10 has an executable.  So I looked at the OpenSolaris
> source out of curiosity and found this.
>
> [CDDL stuff here]
> /*
>  * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
>  * Use is subject to license terms.
>  */
>
> #pragma ident   "%Z%%M% %I%     %E% SMI"
>
> #include <unistd.h>
>
> /*
>  * Exit with a zero value as quickly as possible.
>  */
>
> int
> main(void)
> {
>         _exit(0);
>         /*NOTREACHED*/
>         return (0);
> }
>

Ah, the tyranny of  static analysis tools... _exit(0) should be marked such
that the tools know it does not return. This means the /*NOTREACHED*/ isn't
needed. And since there's no real exit path out of  main, the return (0) is
equally bogus (because main can't return). Yet lint and other tools have
ushered in this insanity.

I'm glad to see these days that these sorts of lame false positives have
been eliminated...

Then again _exit(0) is a useless optimization. It saves three closes for
files that are bound to be closed at image tear down. If it really is that
important (absent data, my gut tells me it isn't), then this should be
written in assembler. FreeBSD/amd64 would be something like:

#include <sys/syscall.h>
#include <machine/asm.h>

ENTRY(_start)
xor %r10, %r10
mov $SYS_exit, %eax
syscall
END(_start)

This some small hacks to each arch's SYS.h in libc, this could even be
smaller and MI :). this is tiny:
-rwxrwxr-x  1 imp  imp  672 Nov 28 10:18 true
  text   data   bss   dec   hex   filename
    10      0     0    10   0xa   true

Contrast that with FreeBSD's /usr/bin/true:
-r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
  text   data   bss    dec     hex   filename
  1540    481     8   2029   0x7ed   /usr/bin/true

which is little more than return(0), but also has a fair amount of
copyright and SCCS data.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/c102ce08/attachment.html>

[TUHS] /bin/true (was basic tools / Universal Unix)

[Dan Cross]

On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> Ah, the tyranny of  static analysis tools... _exit(0) should be marked
> such that the tools know it does not return. This means the /*NOTREACHED*/
> isn't needed. And since there's no real exit path out of  main, the return
> (0) is equally bogus (because main can't return). Yet lint and other tools
> have ushered in this insanity.
>

Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
is called as this calls the exit system call, which cannot -- by definition
-- return. But main() itself can return to whatever calls it (usually
`start`, I'd imagine). For that matter, I'm not aware of any prohibition
against calling `main()` recursively.

: tempest; cat r.c
#include <stdio.h>

int
main(int argc, char *argv[])
{
if (argc > 1) {
argc--; argv++;
printf("%s", argv[0]);
if (argc > 1) printf(" ");
return main(argc, argv);
}
printf("\n");
return 0;
}
: tempest; make r
cc     r.c   -o r
: tempest; ./r hi from Dan
hi from Dan
: tempest;

This is sort of an admittedly weird way to write `echo`, but it seems to
work ok.

I'm glad to see these days that these sorts of lame false positives have
> been eliminated...
>

+1.

Then again _exit(0) is a useless optimization. It saves three closes for
> files that are bound to be closed at image tear down. If it really is that
> important (absent data, my gut tells me it isn't), then this should be
> written in assembler. FreeBSD/amd64 would be something like:
>
> #include <sys/syscall.h>
> #include <machine/asm.h>
>
> ENTRY(_start)
> xor %r10, %r10
> mov $SYS_exit, %eax
> syscall
> END(_start)
>
> This some small hacks to each arch's SYS.h in libc, this could even be
> smaller and MI :). this is tiny:
> -rwxrwxr-x  1 imp  imp  672 Nov 28 10:18 true
>   text   data   bss   dec   hex   filename
>     10      0     0    10   0xa   true
>

This is much smaller than the binary for the assembler program I posted for
macOS earlier in this thread: the result there was much larger (but due to
the requirement to have a non-empty data segment in the executable; this
ends up being page-aligned and filled with zeros).

Contrast that with FreeBSD's /usr/bin/true:
> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>   text   data   bss    dec     hex   filename
>   1540    481     8   2029   0x7ed   /usr/bin/true
>
> which is little more than return(0), but also has a fair amount of
> copyright and SCCS data.
>

Is the copyright data actually present in the object file? I see some RCS
$Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
/usr/bin/true on my system.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/bdce1e28/attachment.html>

[TUHS] /bin/true (was basic tools / Universal Unix)

[Bakul Shah]

On Tue, 28 Nov 2017 10:56:52 -0700 Warner Losh <imp at bsdimp.com> wrote:
Warner Losh writes:
> 
> On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224 at gmail.com> wrote:
> 
> > A late comment:  I seem to recall this boilerplate in earlier Solaris
> > but Solaris 10 has an executable.  So I looked at the OpenSolaris
> > source out of curiosity and found this.
> >
> > [CDDL stuff here]
> > /*
> >  * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
> >  * Use is subject to license terms.
> >  */
> >
> > #pragma ident   "%Z%%M% %I%     %E% SMI"
> >
> > #include <unistd.h>
> >
> > /*
> >  * Exit with a zero value as quickly as possible.
> >  */
> >
> > int
> > main(void)
> > {
> >         _exit(0);
> >         /*NOTREACHED*/
> >         return (0);
> > }
> >
> 
> Ah, the tyranny of  static analysis tools... _exit(0) should be marked such
> that the tools know it does not return. This means the /*NOTREACHED*/ isn't
> needed. And since there's no real exit path out of  main, the return (0) is
> equally bogus (because main can't return). Yet lint and other tools have
> ushered in this insanity.
> 
> I'm glad to see these days that these sorts of lame false positives have
> been eliminated...
> 
> Then again _exit(0) is a useless optimization. It saves three closes for
> files that are bound to be closed at image tear down. If it really is that
> important (absent data, my gut tells me it isn't), then this should be
> written in assembler. FreeBSD/amd64 would be something like:
> 
> #include <sys/syscall.h>
> #include <machine/asm.h>
> 
> ENTRY(_start)
> xor %r10, %r10
> mov $SYS_exit, %eax
> syscall
> END(_start)
> 
> This some small hacks to each arch's SYS.h in libc, this could even be
> smaller and MI :). this is tiny:
> -rwxrwxr-x  1 imp  imp  672 Nov 28 10:18 true
>   text   data   bss   dec   hex   filename
>     10      0     0    10   0xa   true
> 
> Contrast that with FreeBSD's /usr/bin/true:
> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>   text   data   bss    dec     hex   filename
>   1540    481     8   2029   0x7ed   /usr/bin/true
> 
> which is little more than return(0), but also has a fair amount of
> copyright and SCCS data.

int main(void) { return 0; }

is sufficient for true.  BTW this is pretty much what
/usr/src/usr.bin/true/true.c does.

And true can also be a file of length 0 chmoded to +x.  No
need to optimize such things.

It should really be linked staticallly but crt1.o seems to
bring in the entire libc. I guess linking with just the things
a program needs is a hard problem!

[TUHS] /bin/true (was basic tools / Universal Unix)

[Warner Losh]

On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd at gmail.com> wrote:

> On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>> Ah, the tyranny of  static analysis tools... _exit(0) should be marked
>> such that the tools know it does not return. This means the /*NOTREACHED*/
>> isn't needed. And since there's no real exit path out of  main, the return
>> (0) is equally bogus (because main can't return). Yet lint and other tools
>> have ushered in this insanity.
>>
>
> Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
> is called as this calls the exit system call, which cannot -- by definition
> -- return. But main() itself can return to whatever calls it (usually
> `start`, I'd imagine). For that matter, I'm not aware of any prohibition
> against calling `main()` recursively.
>

Ture but completely irrelevant. If exit happens, the process is done. main
isn't going to return because control never returns back to main. That's
what makes the messages completely bogus. Execution simply stops. _exit()
doesn't cause main() to return to _start(), the process stops executing at
that point.

This is much smaller than the binary for the assembler program I posted for
> macOS earlier in this thread: the result there was much larger (but due to
> the requirement to have a non-empty data segment in the executable; this
> ends up being page-aligned and filled with zeros).
>
> Contrast that with FreeBSD's /usr/bin/true:
>> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>>   text   data   bss    dec     hex   filename
>>   1540    481     8   2029   0x7ed   /usr/bin/true
>>
>> which is little more than return(0), but also has a fair amount of
>> copyright and SCCS data.
>>
>
> Is the copyright data actually present in the object file? I see some RCS
> $Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
> /usr/bin/true on my system.
>

Ah yes, I read the source, but hadn't checked the final binary... Most of
the data seems to be other things...  It used to get the copyright data
with gcc a long time ago...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/e92b7118/attachment-0001.html>

[TUHS] /bin/true (was basic tools / Universal Unix)

[Dan Cross]

On Tue, Nov 28, 2017 at 1:41 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd at gmail.com> wrote:
>
>> On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at bsdimp.com> wrote:
>>>
>>> Ah, the tyranny of  static analysis tools... _exit(0) should be marked
>>> such that the tools know it does not return. This means the /*NOTREACHED*/
>>> isn't needed. And since there's no real exit path out of  main, the return
>>> (0) is equally bogus (because main can't return). Yet lint and other tools
>>> have ushered in this insanity.
>>>
>>
>> Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
>> is called as this calls the exit system call, which cannot -- by definition
>> -- return. But main() itself can return to whatever calls it (usually
>> `start`, I'd imagine). For that matter, I'm not aware of any prohibition
>> against calling `main()` recursively.
>>
>
> Ture but completely irrelevant. If exit happens, the process is done. main
> isn't going to return because control never returns back to main. That's
> what makes the messages completely bogus. Execution simply stops. _exit()
> doesn't cause main() to return to _start(), the process stops executing at
> that point.
>

I think perhaps we are talking past one another.

You had written '(because main can't return)' and it seems (if you'll
forgive me putting words in your mouth, so to speak) that you either
intended to say that _exit() can't return, or that main can't return *in
this context* (because it invoked exit). Exit obviously cannot return, as
you and I both explicitly mentioned, but I was addressing the comment that
*main* cannot return. main() absolutely can return, just not _here_.

This is much smaller than the binary for the assembler program I posted for
>> macOS earlier in this thread: the result there was much larger (but due to
>> the requirement to have a non-empty data segment in the executable; this
>> ends up being page-aligned and filled with zeros).
>>
>> Contrast that with FreeBSD's /usr/bin/true:
>>> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>>>   text   data   bss    dec     hex   filename
>>>   1540    481     8   2029   0x7ed   /usr/bin/true
>>>
>>> which is little more than return(0), but also has a fair amount of
>>> copyright and SCCS data.
>>>
>>
>> Is the copyright data actually present in the object file? I see some RCS
>> $Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
>> /usr/bin/true on my system.
>>
>
> Ah yes, I read the source, but hadn't checked the final binary... Most of
> the data seems to be other things...  It used to get the copyright data
> with gcc a long time ago...
>

There is, perhaps, some debugging value in embedding ident strings in
object code: one can see which versions of which sources were used to
construct a given binary. I suspect the incremental value of such things is
diminishing with faster computers and fast (relatively) compilation; it's
easier to simply construct a binary from known versions of source files
than to extrapolate versions of files from a known binary. I can't think of
a great use case for embedding copyright data into an object file, however.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/80a8cb23/attachment.html>

[TUHS] /bin/true (was basic tools / Universal Unix)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

I'm not a lawyer nor play one on TV.   That said, I talk to a lot of them
and have worked for firms that have to deal with this sort of issue.  Your
milage may vary ....

On Tue, Nov 28, 2017 at 2:09 PM, Dan Cross <crossd at gmail.com> wrote:

> I can't think of a great use case for embedding copyright data into an
> object file, however.
>
​This is from some one who used to work for TPC who took out a copyright on
every page in the phone directory.​

As I understand it from my legal folks, it is all post the Franklin/Apple
case.    Making sure all object files also have legally recognized set of
stamps in them.

I suspect one can argue with the judge that a single copyright notice are
coving all of the SCCS stamps on from all the files shipped in the release
(source or binary).  But just like putting a copyright on every page in the
phone book, I think the argument is that a page can ripped from the phone
book and a binary and can copied from a system.   Because of the 'motion'
of the object, making sure every object has a mark is best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/a1a90a56/attachment.html>

[TUHS] /bin/true (was basic tools / Universal Unix)

[Ralph Corderoy]

Hi Dan,

> There is, perhaps, some debugging value in embedding ident strings in
> object code: one can see which versions of which sources were used to
> construct a given binary.

That's died away, but there is a `build ID' that's gained favour with
the pursuit of `reproducable builds', e.g. don't have the compiler add a
timestamp.

    $ readelf -n /bin/true

    Displaying notes found in: .note.ABI-tag
      Owner                 Data size       Description
      GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
	OS: Linux, ABI: 2.6.32

    Displaying notes found in: .note.gnu.build-id
      Owner                 Data size       Description
      GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
	Build ID: 32c992f2f7265996a76ca416c229b92f4c9edcf4
    $ 

https://en.wikipedia.org/wiki/Deterministic_compilation
https://reproducible-builds.org/

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] /bin/true (was basic tools / Universal Unix)

[Ralph Corderoy]

Hi Werner,

> >  * Exit with a zero value as quickly as possible.
> ...
> >         _exit(0);
...
> Then again _exit(0) is a useless optimization. It saves three closes
> for files that are bound to be closed at image tear down.

It also avoids checking the atexit(3) list, yet here on Linux x86_64
with glibc 2.26-6, `_exit(0)' is more instructions to execute than
`return 0', as measured with `perf stat -e instructions ./exit'.

`return 0' can just do

    xor    %eax, %eax
    retq   

whereas _exit makes room on the stack before the JSR, and that's through
the dynamic-linking table, `PLT'.

    sub    $0x8, %rsp
    xor    %edi, %edi
    callq  530 <_exit at plt>

Even with `-static' linking, `return 0' wins on instruction count.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy