allbery@ncoast.UUCP (Brandon Allbery) (04/29/86)
Expires: Quoted from <17555@rochester.ARPA> ["Re: Are any parts of UNIX in public domain?"], by ken@rochester.ARPA (Ipse dixit)... +--------------- | >It is interesting to notice that the previously very small (and fast) | >shell procedure /bin/true now has a size of 747 bytes and a doubled | >execution time. | | Oh, good grief! Do those lawyer types worry about somebody stealing | a one-liner like exit 0? +--------------- It's worse than that... but if I told you, I'd be breaking our license agreement with AT&T, so... Next time you log into a V7, sys3, or even BSD system, do an ``ls -l /bin/test'' and get a surprise that falls out of the way /bin/sh handles exit statuses (statii? :-). --Brandon -- decvax!cwruecmp!ncoast!allbery ncoast!allbery@Case.CSNET ncoast!tdi2!brandon (ncoast!tdi2!root for business) 6615 Center St. #A1-105, Mentor, OH 44060-4101 Phone: +01 216 974 9210 CIS 74106,1032 MCI MAIL BALLBERY (part-time) PC UNIX/UNIX PC - which do you like best? See <1129@ncoast.UUCP> in net.unix.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/29/86)
In article <765@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >Btw, I never use "true". ":" is equivalent, and is more likely to be >a builtin. I've never had a use for "false". Their main use is to hang system-type links on. For example, on the system I'm typing this on, "gould" is linked to "true" and other system types such as "vax" are linked to "false". These commands are very useful if you maintain code for multiple systems all in the same place.
mike@whuxl.UUCP (BALDWIN) (05/02/86)
> In article <765@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: > >Btw, I never use "true". ":" is equivalent, and is more likely to be > >a builtin. I've never had a use for "false". > > Their main use is to hang system-type links on. > For example, on the system I'm typing this on, > "gould" is linked to "true" and other system > types such as "vax" are linked to "false". > These commands are very useful if you maintain > code for multiple systems all in the same place. > [D.Gwyn] The "proper" way to do this is by testing `uname -m`. Linking machine types to /bin/true clutters the name space and makes pattern matching difficult. For instance, how would you do the following "cleanly" using the link /bin/true method: case `uname -m` in 3B*) # 3b specific vax*) # vax specific esac True, "if gould" is prettier than "if [ `uname -m` = gould ]" but that's a poor reason. There need to be some standards on what `uname -m` contains, though. -- Michael Baldwin (not the opinions of) AT&T Bell Laboratories {at&t}!whuxl!mike
greg@ncr-sd.UUCP (Greg Noel) (05/02/86)
In article <401@brl-smoke.ARPA> gwyn@brl.ARPA writes: >[The true and false commands] main use is to hang system-type links on. >For example, on the system I'm typing this on, "gould" is linked to "true" >and other system types such as "vax" are linked to "false". These commands >are very useful if you maintain code for multiple systems all in the same >place. Well, I admit that doing it that way is better than nothing, but I've been in the same environment and I've always considered it a bit of a misfeature. The problem is one of future compatibility -- if you add a new machine type, you have to put in a link on every machine in the world. A better scheme would have been a single command, say "machid", that only consisted of the command "echo gould". Then, the usual sequence of: if pdp11; then ... elif vax; then ... elif pyr; then ... elif gould; then ... elif tower; then ... elif sequent; then ... elif amiga; then ... elif telefunken; then .... else echo "I don't know how to handle this machine"; fi (an exageration, admittedly, but do \you/ have links for all those machines?) becomes: case `machid` in pdp11) ... ;; vax) ... ;; pyr) ... ;; gould) ... ;; tower) ... ;; sequent) ... ;; amiga) ... ;; telefunken) ... ;; *) echo "I don't know how to handle machine-type `machid`" ;; esac This is no more difficult to manage, and easy to extend compatibly. And if you don't have a link for "telefunken" then it doesn't cause your makefile to punt....... -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/03/86)
In article <469@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >... if you add a new machine type, >you have to put in a link on every machine in the world. No, just on the development machines containing code for that machine type. In particular, "elif" won't evaluate the new machine-type command if an earlier instance is satisfied. >A better scheme >would have been a single command, say "machid", that only consisted of the >command "echo gould". Then, the usual sequence of: >... >(an exageration, admittedly, but do \you/ have links for all those machines?) Most of them.. >becomes: > case `machid` in > pdp11) ... ;; >... > *) echo "I don't know how to handle machine-type `machid`" ;; > esac I agree that this is a better approach; `uname -m` is supposed to return a machine-type string like that. However, AT&T did their usual number on "uname" and various vendors were left with no guidance as to the correct meaning of the various fields. Usually they put out useless garbage for `uname -m` instead of the desired generic machine type. N.B. The same machine type should be pre#defined by CPP.
dave@uwvax.UUCP (Dave Cohrs) (05/05/86)
Re: Use "uname -m"
Of course, first, before standardizing what uname prints out, you
need to standardize uname. Despite what AT&T says, sysV is *not*
the standard. It is only *a* standard, which not everyone follows.
uname comes with AT&T systems, not Berkeley systems. Berkeley has
no equivalent command.
--
Dave Cohrs
(608) 262-1204
...!{harvard,ihnp4,seismo,topaz}!uwvax!dave
dave@rsch.wisc.edugreg@ncr-sd.UUCP (Greg Noel) (05/06/86)
In article <523@brl-smoke.ARPA> gwyn@brl.ARPA writes: >In article <469@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >>you have to put in a link on every machine in the world. > >No, just on the development machines containing code for that >machine type. In particular, "elif" won't evaluate the new >machine-type command if an earlier instance is satisfied. Or on any machine to which you ever send code. The technique is more general than just for system development...... >N.B. The same machine type should be pre#defined by CPP. I agree. I still think that the pre-defined symbols should live in a (possibly implementation-specificly named) include file that is perusable by humans; this would also be where the built-in functions would be #defined. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
chris@toram.UUCP (Chris Robertson) (05/07/86)
> In article <765@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: > >Btw, I never use "true". ":" is equivalent, and is more likely to be > >a builtin. I've never had a use for "false". In shell scripts, I find setting a variable to "true" or "false" and then simply saying "if $variable" can often make the code more readable than an explicit "test" or using a case statement. -- Christine Robertson {ihnp4,linus,decvax}!utzoo!toram!chris An apple a day keeps the doctor away, especially if aimed well.
franklin@ut-sally.UUCP (Maurice T. Franklin) (05/08/86)
There has been a considerable amount of discussion on the net recently about
the copyright status of Unix (tm) and the command /bin/true. Seeing the fol-
lowing item on net.jokes, I figured it was time we take a serious (:-) look
at the capabilites of /bin/true. Enjoy, and thanks to Ken Arromdee.
-------------
Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: ut-sally!seismo!umcp-cs!aplcen!jhunix!jor_d015
From: jor_d015@jhunix.UUCP (Ken Arromdee)
Newsgroups: net.jokes
Subject: Yet another manual page (true)
Message-ID: <2691@jhunix.UUCP>
Date: 1 May 86 02:20:53 GMT
Date-Received: 2 May 86 09:43:35 GMT
Reply-To: jor_d015@jhunix.UUCP (Ken Arromdee)
Organization: TARDIS Repairs, Inc.
Lines: 259
TRUE(1) UNIX 5.0 (26 January 1986) TRUE(1)
NAME
/bin/true - Unix version of True
SYNOPSIS
true [ -abcdefghijklmnopqrstuvwxyzBDEFNOZ ]
DESCRIPTION
True is a general-purpose Unix program, often used in shell
scripts. The allowable options are:
-a list
Check user name against list of those permitted to use
/bin/true.
-b Run in batch mode.
-c Produce core dump.
-d Produce debugging output.
-e Ignore end-of-file.
-f Run in /bin/false mode (also see -t)
-g Output garbage to terminal (also see a.out(1))
-h Debugging output in hexadecimal (default octal)
-i Interactive mode
-j Wait until user returns from the john.
-l Create log file.
-m Check to see if the moon is full
-n priority
Run at lower priority (see nice(1))
-o file
Send value to file file instead of to the calling
program.
-p number
Pause number seconds before execution
-q Quick true.
-r [options]
Run rogue(5) before exiting
-s uid
Page 1 (printed 4/26/86)
TRUE(1) UNIX 5.0 (26 January 1986) TRUE(1)
Run setuid mode
-t Run in /bin/false -t mode
-u Use effective instead of real UID.
-v Execute older version of /bin/true, provided for
compatibility.
-w Write a dash followed by the letter "w" to standard
output (see ascii(8))
-x Encryption mode (in Unix (tm) systems sold in the USA
only)
-y Turn terminal yellow.
-z Return zero to calling program
-B Debugging output in binary (default octal)
-D Debugging output in hexadecimal (default octal)
-E Wait until user finishes eating lunch.
-F file
Test to see if file exists (may fail if attempted on a
non-existent file)
-N When debugging, send output to /dev/null.
-O Debugging output in octal.
-S filename
Return to specified shell script instead of calling
program.
-Z Give system privileges to caller.
FILES
/bin/true, /bin/false, /bin/sh, /usr/games/rogue
SEE ALSO
crypt(1), false(1), rogue(5), sh(1), su(1)
NOTES
The original version of this program consisted of no lines;
when the program became over 100 times as large, it was
decided that some essential features be added.
BUGS
Return value is always 0, except with the -f option.
Page 2 (printed 4/26/86)
------------------------------------------------------(source follows)
.TH TRUE 1 "26 January 1986"
.SH NAME
/bin/true \- Unix version of True
.SH SYNOPSIS
\fBtrue\fP [ \-abcdefghijklmnopqrstuvwxyzBDEFNOZ ]
.SH DESCRIPTION
\fITrue\fP is a general-purpose Unix program, often used in shell scripts.
The allowable options are:
.TP
.BI "-a " list
Check user name against list of those permitted to use \fI/bin/true\fP.
.TP
.B -b
Run in batch mode.
.TP
.B -c
Produce core dump.
.TP
.B -d
Produce debugging output.
.TP
.B -e
Ignore end-of-file.
.TP
.B -f
Run in /bin/false mode (also see -t)
.TP
.B -g
Output garbage to terminal (also see \fIa.out(1)\fP)
.TP
.B -h
Debugging output in hexadecimal (default octal)
.TP
.B -i
Interactive mode
.TP
.B -j
Wait until user returns from the john.
.TP
.B -l
Create log file.
.TP
.B -m
Check to see if the moon is full
.TP
.BI "-n " priority
Run at lower priority (see \fInice(1)\fP)
.TP
.BI "-o " file
Send value to file \fIfile\fP instead of to the calling program.
.TP
.BI "-p " number
Pause \fInumber\fP seconds before execution
.TP
.B -q
Quick true.
.TP
.BI "-r " [options]
Run \fIrogue(5)\fP before exiting
.TP
.BI "-s " uid
Run setuid mode
.TP
.B -t
Run in /bin/false -t mode
.TP
.B -u
Use effective instead of real UID.
.TP
.B -v
Execute older version of /bin/true, provided for compatibility.
.TP
.B -w
Write a dash followed by the letter "w" to standard output (see \fIascii(8)\fP)
.TP
.B -x
Encryption mode (in Unix (tm) systems sold in the USA only)
.TP
.B -y
Turn terminal yellow.
.TP
.B -z
Return zero to calling program
.TP
.B -B
Debugging output in binary (default octal)
.TP
.B -D
Debugging output in hexadecimal (default octal)
.TP
.B -E
Wait until user finishes eating lunch.
.TP
.BI "-F " file
Test to see if \fIfile\fP exists (may fail if attempted on a non-existent
file)
.TP
.B -N
When debugging, send output to /dev/null.
.TP
.B -O
Debugging output in octal.
.TP
.BI "-S " filename
Return to specified shell script instead of calling program.
.TP
.BI -Z
Give system privileges to caller.
.SH FILES
/bin/true, /bin/false, /bin/sh, /usr/games/rogue
.SH "SEE ALSO"
crypt(1), false(1), rogue(5), sh(1), su(1)
.SH NOTES
The original version of this program consisted of no lines; when the program
became over 100 times as large, it was decided that some essential features
be added.
.SH BUGS
Return value is always 0, except with the \-f option.
------------------------------------------------(end source)
--
"We are going to give a little something, a few little years more, to
socialism, because socialism is defunct. It dies all by iself. The bad thing
is that socialism, being a victim of its... Did I say socialism?" -Fidel Castro
Kenneth Arromdee
BITNET: G46I4701 at JHUVM and INS_AKAA at JHUVMS
CSNET: ins_akaa@jhunix.CSNET ARPA: ins_akaa%jhunix@hopkins.ARPA
UUCP: ...allegra!hopkins!jhunix!ins_akaa
-------------
"Any sufficiently advanced technology is indistinguishable from magic"
- Arthur C. Clark
Maurice T. Franklin
CS Dept University of Texas at Austin
UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!franklin
ARPA Internet and CSNET: franklin@sally.utexas.edu
[Disclaimer: The University of Texas at Austin, the Computer Science Dept, nor
just about anybody else, is to be held responsible for what I say here.] gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/10/86)
In article <154@toram.UUCP> chris@toram.UUCP (Chris Robertson) writes: >In shell scripts, I find setting a variable to "true" or "false" and then >simply saying "if $variable" can often make the code more readable than an >explicit "test" or using a case statement. Consider the following approach, which has lower overhead: flag= ... if [ stuff-that-needs-to-set-flag ] # for example then flag=y fi ... if [ "$flag" ] then # flag was set fi