* /bin/true (was [TUHS] basic tools / Universal Unix) @ 2017-10-19 14:52 Ron Natalie 2017-10-19 15:01 ` Pete Wright ` (4 more replies) 0 siblings, 5 replies; 28+ messages in thread From: Ron Natalie @ 2017-10-19 14:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* /bin/true (was [TUHS] basic tools / Universal Unix) 2017-10-19 14:52 /bin/true (was [TUHS] basic tools / Universal Unix) Ron Natalie @ 2017-10-19 15:01 ` Pete Wright 2017-10-19 15:17 ` Chet Ramey 2017-10-19 21:23 ` Steffen Nurpmeso ` (3 subsequent siblings) 4 siblings, 1 reply; 28+ messages in thread From: Pete Wright @ 2017-10-19 15:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* /bin/true (was [TUHS] basic tools / Universal Unix) 2017-10-19 15:01 ` Pete Wright @ 2017-10-19 15:17 ` Chet Ramey 0 siblings, 0 replies; 28+ messages in thread From: Chet Ramey @ 2017-10-19 15:17 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* /bin/true (was [TUHS] basic tools / Universal Unix) 2017-10-19 14:52 /bin/true (was [TUHS] basic tools / Universal Unix) Ron Natalie 2017-10-19 15:01 ` Pete Wright @ 2017-10-19 21:23 ` Steffen Nurpmeso 2017-10-19 21:43 ` Chet Ramey 2017-10-19 21:43 ` /bin/true (was [TUHS] " Dave Horsfall ` (2 subsequent siblings) 4 siblings, 1 reply; 28+ messages in thread From: Steffen Nurpmeso @ 2017-10-19 21:23 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 28+ messages in thread
* /bin/true (was [TUHS] basic tools / Universal Unix) 2017-10-19 21:23 ` Steffen Nurpmeso @ 2017-10-19 21:43 ` Chet Ramey 2017-10-19 23:00 ` [TUHS] /bin/true (was " Dave Horsfall 0 siblings, 1 reply; 28+ messages in thread From: Chet Ramey @ 2017-10-19 21:43 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 21:43 ` Chet Ramey @ 2017-10-19 23:00 ` Dave Horsfall 2017-10-19 23:14 ` Grant Taylor 2017-10-20 12:10 ` Chet Ramey 0 siblings, 2 replies; 28+ messages in thread From: Dave Horsfall @ 2017-10-19 23:00 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 23:00 ` [TUHS] /bin/true (was " Dave Horsfall @ 2017-10-19 23:14 ` Grant Taylor 2017-10-19 23:23 ` Lyndon Nerenberg 2017-10-19 23:27 ` Kurt H Maier 2017-10-20 12:10 ` Chet Ramey 1 sibling, 2 replies; 28+ messages in thread From: Grant Taylor @ 2017-10-19 23:14 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 23:14 ` Grant Taylor @ 2017-10-19 23:23 ` Lyndon Nerenberg 2017-10-19 23:27 ` Kurt H Maier 1 sibling, 0 replies; 28+ messages in thread From: Lyndon Nerenberg @ 2017-10-19 23:23 UTC (permalink / raw) : lyndon at orthanc:/home/lyndon; cat ./cd #!/bin/sh builtin cd $1 && /bin/sh -i ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 23:14 ` Grant Taylor 2017-10-19 23:23 ` Lyndon Nerenberg @ 2017-10-19 23:27 ` Kurt H Maier 2017-10-22 4:18 ` Dave Horsfall 1 sibling, 1 reply; 28+ messages in thread From: Kurt H Maier @ 2017-10-19 23:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 23:27 ` Kurt H Maier @ 2017-10-22 4:18 ` Dave Horsfall 0 siblings, 0 replies; 28+ messages in thread From: Dave Horsfall @ 2017-10-22 4:18 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 23:00 ` [TUHS] /bin/true (was " Dave Horsfall 2017-10-19 23:14 ` Grant Taylor @ 2017-10-20 12:10 ` Chet Ramey 1 sibling, 0 replies; 28+ messages in thread From: Chet Ramey @ 2017-10-20 12:10 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* /bin/true (was [TUHS] basic tools / Universal Unix) 2017-10-19 14:52 /bin/true (was [TUHS] basic tools / Universal Unix) Ron Natalie 2017-10-19 15:01 ` Pete Wright 2017-10-19 21:23 ` Steffen Nurpmeso @ 2017-10-19 21:43 ` Dave Horsfall 2017-10-19 22:04 ` Ronald Natalie [not found] ` <CAEoi9W7YZ7YXUip0JTMGip3Nd0czgdjqRCMRcK2GYmDJsckuDg@mail.gmail.com> 2017-11-28 16:21 ` Nemo 4 siblings, 1 reply; 28+ messages in thread From: Dave Horsfall @ 2017-10-19 21:43 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 28+ messages in thread
* /bin/true (was [TUHS] basic tools / Universal Unix) 2017-10-19 21:43 ` /bin/true (was [TUHS] " Dave Horsfall @ 2017-10-19 22:04 ` Ronald Natalie 2017-10-19 23:25 ` [TUHS] /bin/true (was " Dave Horsfall 0 siblings, 1 reply; 28+ messages in thread From: Ronald Natalie @ 2017-10-19 22:04 UTC (permalink / raw) [-- 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.” ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 22:04 ` Ronald Natalie @ 2017-10-19 23:25 ` Dave Horsfall 0 siblings, 0 replies; 28+ messages in thread From: Dave Horsfall @ 2017-10-19 23:25 UTC (permalink / raw) [-- 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." ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <CAEoi9W7YZ7YXUip0JTMGip3Nd0czgdjqRCMRcK2GYmDJsckuDg@mail.gmail.com>]
[parent not found: <CAEoi9W4zdJ3+RXjK5-5rAJ6rwx_0kx6N-bn1U61=txJGyLT_mw@mail.gmail.com>]
* [TUHS] /bin/true (was basic tools / Universal Unix) [not found] ` <CAEoi9W4zdJ3+RXjK5-5rAJ6rwx_0kx6N-bn1U61=txJGyLT_mw@mail.gmail.com> @ 2017-10-20 1:27 ` Dan Cross 2017-10-20 1:31 ` Lyndon Nerenberg 0 siblings, 1 reply; 28+ messages in thread From: Dan Cross @ 2017-10-20 1:27 UTC (permalink / raw) [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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-20 1:27 ` Dan Cross @ 2017-10-20 1:31 ` Lyndon Nerenberg 2017-10-20 2:05 ` Ronald Natalie 0 siblings, 1 reply; 28+ messages in thread From: Lyndon Nerenberg @ 2017-10-20 1:31 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-20 1:31 ` Lyndon Nerenberg @ 2017-10-20 2:05 ` Ronald Natalie 0 siblings, 0 replies; 28+ messages in thread From: Ronald Natalie @ 2017-10-20 2:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-19 14:52 /bin/true (was [TUHS] basic tools / Universal Unix) Ron Natalie ` (3 preceding siblings ...) [not found] ` <CAEoi9W7YZ7YXUip0JTMGip3Nd0czgdjqRCMRcK2GYmDJsckuDg@mail.gmail.com> @ 2017-11-28 16:21 ` Nemo 2017-11-28 17:56 ` Warner Losh 4 siblings, 1 reply; 28+ messages in thread From: Nemo @ 2017-11-28 16:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 16:21 ` Nemo @ 2017-11-28 17:56 ` Warner Losh 2017-11-28 18:26 ` Dan Cross ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Warner Losh @ 2017-11-28 17:56 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 17:56 ` Warner Losh @ 2017-11-28 18:26 ` Dan Cross 2017-11-28 18:41 ` Warner Losh 2017-11-28 18:34 ` Bakul Shah 2017-11-28 23:25 ` Ralph Corderoy 2 siblings, 1 reply; 28+ messages in thread From: Dan Cross @ 2017-11-28 18:26 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 18:26 ` Dan Cross @ 2017-11-28 18:41 ` Warner Losh 2017-11-28 19:09 ` Dan Cross 0 siblings, 1 reply; 28+ messages in thread From: Warner Losh @ 2017-11-28 18:41 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 18:41 ` Warner Losh @ 2017-11-28 19:09 ` Dan Cross 2017-11-28 20:34 ` Clem Cole 2017-11-28 22:42 ` Ralph Corderoy 0 siblings, 2 replies; 28+ messages in thread From: Dan Cross @ 2017-11-28 19:09 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 19:09 ` Dan Cross @ 2017-11-28 20:34 ` Clem Cole 2017-11-28 22:42 ` Ralph Corderoy 1 sibling, 0 replies; 28+ messages in thread From: Clem Cole @ 2017-11-28 20:34 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 19:09 ` Dan Cross 2017-11-28 20:34 ` Clem Cole @ 2017-11-28 22:42 ` Ralph Corderoy 1 sibling, 0 replies; 28+ messages in thread From: Ralph Corderoy @ 2017-11-28 22:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 17:56 ` Warner Losh 2017-11-28 18:26 ` Dan Cross @ 2017-11-28 18:34 ` Bakul Shah 2017-11-28 23:25 ` Ralph Corderoy 2 siblings, 0 replies; 28+ messages in thread From: Bakul Shah @ 2017-11-28 18:34 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-11-28 17:56 ` Warner Losh 2017-11-28 18:26 ` Dan Cross 2017-11-28 18:34 ` Bakul Shah @ 2017-11-28 23:25 ` Ralph Corderoy 2 siblings, 0 replies; 28+ messages in thread From: Ralph Corderoy @ 2017-11-28 23:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix)
@ 2017-10-22 23:00 Doug McIlroy
2017-10-23 1:11 ` Dan Cross
0 siblings, 1 reply; 28+ messages in thread
From: Doug McIlroy @ 2017-10-22 23:00 UTC (permalink / raw)
> 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.
Not quite. The classic empty executable file for /bin/true works
on OS X. That is not just a clever trick;it's a natural consequence
of Kernighan's ancient prrecept: do nothing gracefully. Conceivably
the 4K data section is, too--if the page has no physical presence
until it is accessed.
Doug
^ permalink raw reply [flat|nested] 28+ messages in thread
* [TUHS] /bin/true (was basic tools / Universal Unix) 2017-10-22 23:00 Doug McIlroy @ 2017-10-23 1:11 ` Dan Cross 0 siblings, 0 replies; 28+ messages in thread From: Dan Cross @ 2017-10-23 1:11 UTC (permalink / raw) On Sun, Oct 22, 2017 at 7:00 PM, Doug McIlroy <doug at cs.dartmouth.edu> 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. > > Not quite. The classic empty executable file for /bin/true works > on OS X. That is not just a clever trick;it's a natural consequence > of Kernighan's ancient prrecept: do nothing gracefully. Conceivably > the 4K data section is, too--if the page has no physical presence > until it is accessed. Oh sure! Sorry; the mention of the 4K data section was meant to be orthogonal to the empty-shell file thing. However, one still cannot 'exec' an empty shell script, even on OS X: : hurricane; mkdir t : hurricane; cd t /Users/dcross/t : hurricane; touch true : hurricane; cat>dotrue.c int main() { execl("./true", "true", 0); write(2, "Boo\n", 4); return 1; } : hurricane; chmod +x ./true : hurricane; ./true : hurricane; echo $? 0 : hurricane; make dotrue cc dotrue.c -o dotrue dotrue.c:1:14: warning: implicit declaration of function 'execl' is invalid in C99 [-Wimplicit-function-declaration] int main() { execl("./true", "true", 0); write(2, "Boo\n", 4); return 1; } ^ dotrue.c:1:42: warning: implicit declaration of function 'write' is invalid in C99 [-Wimplicit-function-declaration] int main() { execl("./true", "true", 0); write(2, "Boo\n", 4); return 1; } ^ 2 warnings generated. : hurricane; ./dotrue Boo : hurricane; echo $? 1 : hurricane; cp /usr/bin/true . : hurricane; ./dotrue : hurricane; echo $? 0 : hurricane; file true true: Mach-O 64-bit executable x86_64 : hurricane; ls -l true -rwxr-xr-x 1 dcross eng 17760 Oct 22 21:08 true : hurricane; cd .. /Users/dcross : hurricane; rm -fr t : hurricane; (The system-provided /usr/bin/true is >16KB!!) - Dan C. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2017-11-28 23:25 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-19 14:52 /bin/true (was [TUHS] basic tools / Universal Unix) Ron Natalie 2017-10-19 15:01 ` Pete Wright 2017-10-19 15:17 ` Chet Ramey 2017-10-19 21:23 ` Steffen Nurpmeso 2017-10-19 21:43 ` Chet Ramey 2017-10-19 23:00 ` [TUHS] /bin/true (was " Dave Horsfall 2017-10-19 23:14 ` Grant Taylor 2017-10-19 23:23 ` Lyndon Nerenberg 2017-10-19 23:27 ` Kurt H Maier 2017-10-22 4:18 ` Dave Horsfall 2017-10-20 12:10 ` Chet Ramey 2017-10-19 21:43 ` /bin/true (was [TUHS] " Dave Horsfall 2017-10-19 22:04 ` Ronald Natalie 2017-10-19 23:25 ` [TUHS] /bin/true (was " Dave Horsfall [not found] ` <CAEoi9W7YZ7YXUip0JTMGip3Nd0czgdjqRCMRcK2GYmDJsckuDg@mail.gmail.com> [not found] ` <CAEoi9W4zdJ3+RXjK5-5rAJ6rwx_0kx6N-bn1U61=txJGyLT_mw@mail.gmail.com> 2017-10-20 1:27 ` Dan Cross 2017-10-20 1:31 ` Lyndon Nerenberg 2017-10-20 2:05 ` Ronald Natalie 2017-11-28 16:21 ` Nemo 2017-11-28 17:56 ` Warner Losh 2017-11-28 18:26 ` Dan Cross 2017-11-28 18:41 ` Warner Losh 2017-11-28 19:09 ` Dan Cross 2017-11-28 20:34 ` Clem Cole 2017-11-28 22:42 ` Ralph Corderoy 2017-11-28 18:34 ` Bakul Shah 2017-11-28 23:25 ` Ralph Corderoy 2017-10-22 23:00 Doug McIlroy 2017-10-23 1:11 ` Dan Cross
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).