jac@eagles.rutgers.edu (Jonathan A. Chandross) (04/02/88)
Enclosed is a public domain version of Berkeley's yes(1) program. I find
it to be invaluable.
This project started when I discovered that my friends who used System V,
Version 7, and Minix did not have this program. So I sat down and over
the next 4 months managed to write this version of yes(1). Since this
code does not contain any AT&T or Berkely code it can be freely distributed.
I hereby place this code in the public domain.
I would like to point out that this code is about twice as fast as the
Berkeley version. Placing argv[1] in a buffer and using puts() should
speed it up even further.
If anyone is interested in writing a man page, let me know and I'll be glad
to help.
Jonathan A. Chandross
ARPA: jac@paul.rutgers.edu
UUCP: rutgers!jac@paul.rutgers.edu
---------
Cut here
---------
/* */
/* yes(1) */
/* */
/* yes repeatedly outputs "y" or an optionial argument. */
/* */
/* Author: Jonathan A. Chandross January 17 - April 1, 1988 */
/* */
main(argc, argv)
int argc;
char **argv;
{
if(argc > 1)
for (;;)
printf("%s\n", argv[1]);
else
for (;;)
printf("y\n");
}honey@umix.cc.umich.edu (Peter Honeyman) (04/02/88)
#!/bin/sh
while :; do
echo ${1-y}
done
i know it was a joke ... but so is ucb's version.chongo@amdahl.uts.amdahl.com (Landon Curt Noll) (04/03/88)
In article <Apr.1.21.15.54.1988.3010@eagles.rutgers.edu> jac@eagles.rutgers.edu (Jonathan A. Chandross) writes: >Enclosed is a public domain version of Berkeley's yes(1) program. I find >it to be invaluable. > >If anyone is interested in writing a man page, let me know and I'll be glad >to help. And to continue the joke, be sure that the yes(1) man page BUGS section reads: Very Boring. chongo <that is Un*x tradition afterall :-}> /\oo/\ -- [views above shouldn't be viewed as Amdahl views, or as views from Amdahl, or as Amdahl views views, or as views by Mr. Amdahl, or as views from his house]
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/05/88)
As you all know, some UNIX users alias "rm" to "rm -i", even though
this is unwise.
Once you alias "rm" to "rm -i", deleting files becomes a hassle. So
you can now do
rm < yes
to delete specified files without having to type y for each file.
Thus for some people yes(1) serves a valuable purpose. We should not
make fun of them. No doubt the Berkeley programmers had such uses in
mind when they thoughtfully decided to include yes(1) as part of the
standard 4.xBSd distribution, so that we would not have to depend on
unsupported, possibly unreliable public domain versions.
We should not make fun of the fact that the source for yes(1) as
supplied with 4.xBSD is proprietary. AT&T has spent many millions of
dollars developing UNIX, and Berkeley has used this source code to
create 4.xBSD. Thus it is only fair that if you want Berkeley's
version of yes(1), then AT&T should get its royalty for the UNIX source
that it is based on. This is why you need an AT&T source license in
order to get the source for yes(1).
We should also not forget that the public domain version of yes(1) is a
clone of the original, and certainly look-and-feel issues apply.
Certainly I see nothing in the public domain version that distinguishes
its behavior from the original. Come now folks, if you must copy
somebody else's concept, at least throw in a few original features!
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesiwnp@chinet.UUCP (Wolf N. Paul) (04/05/88)
In article <2561@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > ... No doubt the Berkeley programmers had such uses in >mind when they thoughtfully decided to include yes(1) as part of the >standard 4.xBSd distribution, so that we would not have to depend on >unsupported, possibly unreliable public domain versions. > >We should not make fun of the fact that the source for yes(1) as >supplied with 4.xBSD is proprietary. AT&T has spent many millions of >dollars developing UNIX, and Berkeley has used this source code to >create 4.xBSD. ... I am sure they spent millions of dollars developing the source code for the System V Release 2 version of true(1). If that can be proprietary, unpublished source code, then yes(1) most certainly qualifies. At least yes(1) DOES CONTAIN CODE! >We should also not forget that the public domain version of yes(1) is a >clone of the original, and certainly look-and-feel issues apply. >Certainly I see nothing in the public domain version that distinguishes >its behavior from the original. Come now folks, if you must copy >somebody else's concept, at least throw in a few original features! As they would say at Apple(tm), "This is our way of doing things. If others want to do the same thing, at least they can come up with their own way of doing it! So we'll sue the author of public domain yes(1) to intimidate Stallman and Gilmore etc. into ceasing and desisting from their work on GNU." Apple is a Trade Mark of Apple Computer (WA Apple Growers Beware! What are you going to call your product when Apple Computer decides to sue you?) Wolf Paul wnp@chinet convex!mcomp!dcs!wnp
Pete Holsberg@mccc.UUCP (Peter J. Holsberg) (04/05/88)
Just say no(1)!
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800klee@daisy.UUCP (Ken Lee) (04/06/88)
In article <2561@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >As you all know, some UNIX users alias "rm" to "rm -i", even though >you can now do > rm < yes >to delete specified files without having to type y for each file. I take it you really meant "yes | rm". A much cleaner solution is just \rm Ken -- New simplified tax form: Line 1: how much money did you make? Line 2: send it to the IRS.
klaiber@udel.EDU (Alexander Klaiber) (04/06/88)
In article <4571@chinet.UUCP> wnp@chinet.UUCP (Wolf N. Paul) writes: >I am sure they spent millions of dollars developing the source code for >the System V Release 2 version of true(1). If that can be proprietary, >unpublished source code, then yes(1) most certainly qualifies. At least >yes(1) DOES CONTAIN CODE! Well, if true(1) is proprietary and contans no code, then every other program written contains the code for true(1) and hence violates copyright laws.... maybe that way, AT&T will get back its millions? Alexander Klaiber klaiber@dewey.udel.edu
aeusemrs@csuna.UUCP (Mike Stump) (04/07/88)
In article <1896@louie.udel.EDU> klaiber@udel.EDU (Alexander Klaiber) writes:
-Well, if true(1) is proprietary and contans no code, then every other
-program written contains the code for true(1) and hence violates copyright
-laws.... maybe that way, AT&T will get back its millions?
-
-Alexander Klaiber
Well, one would be in violation only if one had done a cat /bin/true >>myfile
--
Mike Stump, Cal State Univ, Northridge Comp Sci Department
uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!csuna!aeusemrsjca@rolls.UUCP (James C. Armstrong) (04/08/88)
I have watched all of these varieties of yes(1) come whizzing by, and must wonder: Are you all all that bad? If you look closely, you'll see that you are doing a comparision on each execution! Why not: if [ "$#" -gt 1 ] then ans=$* else ans=y fi while true do echo $ans done Check what you want to echo ONCE ONLY, assign it and echo it.
sarge@fraud.Berkeley.EDU (Steven Sargent) (04/09/88)
> If you look closely, you'll see that you are doing a comparision on each > > if [ "$#" -gt 1 ] > then > ans=$* > else > ans=y > fi > while true > do > echo $ans > done > > Check what you want to echo ONCE ONLY, assign it and echo it. Why not? 1. It's wrong -- doesn't implement the spec (4bsd manual page) in two ways: it should only echo $1, not $*; also, you should use -ge, not -gt. 2. Any puny performance advantage you might get from doing the test only once is completely swamped by the exec penalty on true, once per loop. Benchmark your version against *** cut here #!/bin/sh while :; do echo ${1-y} done *** end Recall that ${1-y} is built into the shell. test may or may not be (it isn't on 4bsd; is in V.3). : also is built-in. If you need more complicated stuff than $ provides, "case" covers a lot of situations, again without exec. The manual page gives much cryptic info here. 3. (careful, big words coming up) Your adding the spurious temporary variable "ans" breaks an otherwise referentially transparent program; the fact that doing so confers no compensating performance advantage is all the worse. > I have watched all of these varieties of yes(1) come whizzing by, and > must wonder: Are you all all that bad? "We all" may be hurling a lot of cement pies your way; maybe you should leave town for awhile? Steven "Trust but verify" Sargent. --- "I'm sorry... you must have me confused with some other plate-lipped white girl named Irene." -- Good Girls #2 Steven Sargent ARPA Internet: sarge@scam.berkeley.edu MILnet: sarge%scam.berkeley.edu@ucbvax.berkeley.edu TPCnet: {anywhere at all, really}!ucbvax!scam!sarge
jerryp@cmx.npac.syr.edu (Jerry Peek) (04/10/88)
[Sorry if this is the wrong newsgroup; I don't see an "alt.sources.d"...] In article <2561@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > As you all know, some UNIX users alias "rm" to "rm -i", even though > this is unwise. > > Once you alias "rm" to "rm -i", deleting files becomes a hassle. So > you can now do > > rm < yes > > to delete specified files without having to type y for each file. He means yes | rm filenames... Rahul's example would make the "rm" command read its answers from a *file* named "yes" (not the *command*). --Jerry Peek, Northeast Parallel Architectures Center, Syracuse, NY jerryp@amax.npac.syr.edu (315)423-1722
gaynor@porthos.rutgers.edu (Silver) (04/11/88)
Hi everybody! Since we're so intent on continuing this discussion,
and I need a break from the *real* stuff for a minute, I decided to
write my own yes! I phoned my folks, and got my mom to work on her
version in Lotus. My dad doesn't know any computer languages, but at
least he can type for my mom... Rex (our dog) knows Logo, and is
de-flea-ing his version as I tap. I've posted calls for versions to
all the networks and PA-Unix boxes to which I have easy access; I
volunteer to painfully post each one seperately.
This satisfies my sun's man page of yes.
==================== yes.c ====================
/************************* DISCLAIMER **************************\
* PUBLIC DOMAIN, DAMAGES DISCLAIMED! [Ag] gaynor@rutgers.edu *
\***************************************************************/
/********************** yes [ expletive ] **********************\
* *
* Continuously output an expletive until terminated externally. *
* Expletive may be supplied as an argument on the command line, *
* defaulting to "y" if not. *
* *
\***************************************************************/
#include <stdio.h>
int main(argc, argv)
int argc;
char * argv[];
{char * expletive; /* Points to the string which is to be output. */
{/* Parse arguments: Set expletive to optional argument if
supplied, or "y" otherwise. */
switch (argc)
{case 1: expletive = "y";
break;
case 2: expletive = argv[1];
break;
default: (void) fprintf(stderr, "usage: %s [ expletive ]\n", argv[0]);
exit(1);}}
{/* Do work: Output expletive continuously. */
forever: /* Ha! A structured use of goto! */
(void) puts(expletive);
goto forever;}}
==================== yes.c ====================davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/11/88)
gaynor@porthos.rutgers.edu (Silver) writes: P.D. version of yes, ending in: > forever: /* Ha! A structured use of goto! */ > (void) puts(expletive); > goto forever;}} Since we're having fun with this, how about: #define ever (;;) for ever (void) puts(expletive); -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
zzmartin@unidui.UUCP (Martin Nicolay) (04/11/88)
In article <2561@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >We should not make fun of the fact that the source for yes(1) as >supplied with 4.xBSD is proprietary. AT&T has spent many millions of >dollars developing UNIX, and Berkeley has used this source code to >create 4.xBSD. Thus it is only fair that if you want Berkeley's >version of yes(1), then AT&T should get its royalty for the UNIX source >that it is based on. This is why you need an AT&T source license in >order to get the source for yes(1). I don't know what kind of software can be copyrighted in the USA. In Germany nobody can copyright an algorithm. Softeware can only be protected if and only if the progammer can express his/her own style (the programming must have been a kind of art). In Germany there can't be a copyright on yes(1). (Neither on true(1) :-) "the artist" :-) ----- *--------------------------------------------------------* * Martin Nicolay * * Fliederstr. 23, 4100 Duisburg 1, W.-Germany * * UUCP: {rest of the wild world}!unido!unidui!zzmartin * * VOICE: (University) +45-203-379-2363 * *--------------------------------------------------------* WARNING: Don't trust upon my opinion, it may change with future releases.
cline@pnet01.cts.com (Ben Humphreys) (04/12/88)
> yes | rm filenames...
If yes's output has to complete before rm's processing is to begin, how does
yes know when to stop (forgive such a niave question please)?
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!cline
ARPA: crash!pnet01!cline@nosc.mil
INET: cline@pnet01.CTS.COMdhesi@bsu-cs.UUCP (Rahul Dhesi) (04/12/88)
In article <2561@bsu-cs.UUCP> I wrote: > rm < yes I thank the many people who send me email pointing out that the correct way to use yes(1) with rm (aliased to "rm -i") is: yes | rm I stand corrected. However, this led me to realize that it would be far more efficient to have a special device, so one could simply do: rm < /dev/yes Pipes are well-known to be inefficient, and it makes no sense to create a new yes process when /dev/yes would be so much faster. I am working on writing /dev/yes and will submit it to comp.sources.unix eventually. I will also attempt to create a similar device for VAX/VMS to handle DELETE being redefined as DELETE/CONFIRM. On VAX/VMS such a device is critically needed because VMS does not have pipes. Thanks to all who supplied feedback for their dedication to the cause of more user-friendly computing. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
madd@bu-cs.BU.EDU (Jim Frost) (04/13/88)
In article <2797@crash.cts.com> cline@pnet01.cts.com (Ben Humphreys) writes: |> yes | rm filenames... | |If yes's output has to complete before rm's processing is to begin, how does |yes know when to stop (forgive such a niave question please)? Forgive such a simple answer, but: MINIX multitasks; both commands run simultaneously. This is unlike MS-DOS which accomplishes piping by saving output in a file until the first program finishes and then running the second, basically the same as: % command1 >tmpfile; command2 <tmpfile It works the same except when you really expect both programs to operate at the same time. For those who haven't tried it, try writing popen()/pclose() under MS-DOS. It's educational. jim frost madd@bu-it.bu.edu
wnp@killer.UUCP (Wolf Paul) (04/14/88)
In article <2797@crash.cts.com> cline@pnet01.cts.com (Ben Humphreys) writes: >> yes | rm filenames... > >If yes's output has to complete before rm's processing is to begin, how does >yes know when to stop (forgive such a niave question please)? ^^^^ It doesn't. As soon as rm is done, it closes its end of the pipe; next time yes tries to write to the pipe (as I said, it doesn't know that rm is done), the write fails because the pipe has been closed at the reading end, and yes dies with the error message, "broken pipe" (at least on 4.2 that's the way it behaves). Also of course, yes' output does not have to complete before rm begins - this is happening concurrently. Remember, UNIX is multi-tasking :-). Yes only needs to output one line before rm can delete the first file, and so on, one line of "yes" output per deleted file. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: ihnp4!killer!dcs!wnp ESL: 62832882 INTERNET: wnp@EESDES.DAS.NET or wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD One Austrian's Opinion: Waldheim must go!
levy@ttrdc.UUCP (Daniel R. Levy) (04/14/88)
In article <2606@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > > rm < /dev/yes > > Pipes are well-known to be inefficient, and it makes no sense to create > a new yes process when /dev/yes would be so much faster. PIPES! Why didn't I think of that before. It's easy to kludge a "/dev/yes" capability on systems that support named pipes; just put something like this in the system startup script: if [ ! -p /dev/yes ]; then /etc/mknod /dev/yes p; fi # create a FIFO chown root /dev/yes chmod 644 /dev/yes sh -c 'while :; do while :; do echo y; done >/dev/yes; done' & Since the process is already running, and echo and ':' are shell builtins, there is little overhead. The nested loop is required since the inner loop dies with EPIPE (broken pipe) whenever a process reading from /dev/yes is killed, dies, or closes its file descriptor open onto the pipe. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Data Systems Group | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
tif@cpe.UUCP (04/16/88)
Written 9:47 pm Apr 4, 1988 by bsu-cs.UUCP!dhesi >As you all know, some UNIX users alias "rm" to "rm -i", even though >this is unwise. > >Once you alias "rm" to "rm -i", deleting files becomes a hassle. So >you can now do > > rm < yes > >to delete specified files without having to type y for each file. of course he new it was really "yes | rm" I'm going to alias "rm" to "yes | rm -i" Yes, I know I'm two weeks late. Paul Chamberlain Computer Product Engineering, Tandy Corp. ihnp4!sys1!cpe!tif
terry@wsccs.UUCP (Every system needs one) (04/30/88)
In article <2797@crash.cts.com>, cline@pnet01.cts.com (Ben Humphreys) writes: > > yes | rm filenames... > > If yes's output has to complete before rm's processing is to begin, how does > yes know when to stop (forgive such a niave question please)? "Broken Pipe" terry@wsccs