Stupid man pages
Schakerianitisadium
would appreciate. ...and even then I'm not sure. Sigh.
This is from a decstation. Look at the first #include.
getsockname(2)
NAME
getsockname - get socket name
SYNTAX
#include <sys/typos.h>
#include <sys/socket.h>
getsockname(s, name, namelen)
int s;
struct sockaddr *name;
int *namelen;
.
.
.
And here's one from UNICOS on a Cray.
NM(1)
NAME
nm - Prints name list
SYNOPSIS
nm -g [-a] [-o] [-u] [-x] [-c] [-v] file
DESCRIPTION
.
.
.
The -g argument is required.
.
.
.
_---_ Stefan Chakerian
/ o o \ sch...@hydra.unm.edu, sch...@unmb.bitnet
| \___/ |
\_____/ Have a nice day... SOMEWHERE ELSE.
Tony Shaughnessy
>Here are two humorous manual pages that only this audience
>would appreciate. ...and even then I'm not sure. Sigh.
>
Anyone on an HP 9000/800 running HP-UX 2.1 (and probably 3.1, 7.x etc)
should try
man tunefs
Under the BUGS section it says (from memory)
"You can tune a file system, but you can't tune a fish"
Tony Shaughnessy
to...@pyra.co.uk
Mike Smithwick
>Here are two humorous manual pages that only this audience
>would appreciate. ...and even then I'm not sure. Sigh.
>
In one of the earlier releases of the Sun OS, the man page for "find" said
in the bugs section :
"the syntax of this command is painful"
How true.
*** mike smithwick ***
"I'm totally awed by what you've done!" (Arthur C. Clarke
commenting about Distant Suns)
[disclaimer : nope, I don't work for NASA, I take full blame for my ideas]
Guy Harris
>in the bugs section :
>
> "the syntax of this command is painful"
(Actually, I think it was just "The syntax is painful.") That one dates
back, I think, to V7; it wasn't Sun's idea (perhaps the same manager who
took out the "You can tune a file system, but you can't tune a fish"
line from TUNEFS(8) took that entry from the BUGS section out. S/he
missed the same line in the ETHERFIND(8C) manual page ("etherfind"s
syntax is derived from that of "find").
The line I like that *was* added at Sun is from the C shell manual page:
Although robust enough for general use, adventures into the
esoteric periphery of the C shell may reveal unexpected
quirks.
which is a polite way of saying "the C shell is often flakier than a
snowstorm"....
Guy Harris
or 4.[23]BSD, for that matter; Berkeley put the "You can tune a file
system, but you can't tune a fish" line in. Unfortunately, some manager
at Sun had them take it out of their "tunefs" manual page....
Guy Harris
>
> BUGS
> British spelling was done by an American.
Yet another one that dates back to V7....
Robert Garvey
BUGS
British spelling was done by an American.
Robert Garvey Sybase, Inc
rob...@sybase.com 6475 Christie Ave
{sun,lll-tis,pyramid,pacbell}!sybase!robert Emeryville, CA 94608
Paul Davey
My favorite (apart from the classic find)-
BUGS
Acts oddly on nights with full moons.
[catman(8) - 4.3bsd on Acorn]
--
Regards, pa...@ixi.uucp IXI Limited
Paul Davey ...!uunet!ixi!paul 62-74 Burleigh Street
+44 224 462 132 (fax) Cambridge U.K.
"These are interesting times" +44 223 462 131 (vox) CB1 1OJ
Bill Stewart 201-949-0705 erebus.att.com!wcs
]>Anyone on an HP 9000/800 running HP-UX 2.1 (and probably 3.1, 7.x etc)
]or 4.[23]BSD, for that matter; Berkeley put the "You can tune a file
]system, but you can't tune a fish" line in. Unfortunately, some manager
]at Sun had them take it out of their "tunefs" manual page....
For a historical view of "when did the bureaucrats notice UNIX at AT&T",
try "grep braindamage /etc/termcap" on different System V versions.
(Somewhere around SVR2.0P or SVR2.1; our old VAXen have retired so I
don't have a machine of the right vintage to check.)
I suspect that what got to them wasn't so much the Hazeltine
section (the 1552 was "the first Hazeltine which is not braindamaged")
now (whitewashed somewhat), but the part about our older Teletypes:
# They have lots of awful braindamage, such as printing visible newlines
# The 40-4 is a 3270 lookalike and beyond hope.
Amazing what happens when managers notice what they've been selling
for years :-)
Bill
--
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Fax 949-4876. Sometimes found at Somerset 201-271-4712
# When *everything* is outlawed, only outlaws will have everything!
Mike Smithwick
Check out crash(8) in the SunOS manual. Under the Diagnositics section
you'll find such wise sayings as : "You should fix your disk if it is
broken or unreliable", and "This is bad news, as no new users will then be
able to log on", and ". . . random flakiness seems to cause this sometimes"
*** mike smithwick ***
"This is a tale of sex, lies and junkfood" - Twin Peaks
Linda Foster
I'm surprised no one has mentioned the classic from reboot(8) in 4.3BSD:
"-n option avoids the sync. It can be used if a disk or the processor
is on fire."
*linda*
William Walker
Due to the
unreliability of the transport protocol (UDP) and the scar-
city of TFTP implementations, it is uncertain whether it
really works.
bill.
Anthony A. Datri
> [catman(8) - 4.3bsd on Acorn]
My favorite is the page for "fed", which you can find in older Unicies (like
the 4.2 Usenix books. This was/is a font editor for some HP terminal. At
the bottom under BUGS was something like
"... the HP 26nn terminal on which this runs has been stolen."
The same set of books have under BUGS for sigvec(2):
This manual page is confusing.
A check on our 11/750 (A VAX with 11/ in front of it isn't a real VAX) running
4.3 gives:
BUGS
This manual page is still confusing.
Many vendors (includingus, sadly) have been "professionalizing" these pages,
which takes some of the fun out of unix.
Lands root
I at least find it amusing :-)
(Hope I ain't breaking any copyrights by posting it in it's entirety)
Frank.
----------------------------------------------------------------------------
Frank Goodman arpa: spa...@CED.Berkeley.EDU
University of California, Berkeley or: spanki%C...@jade.Berkeley.EDU
College of Environmental Design uucp: ...hplabs!ucbvax!ced!spanki
S.I.S Research Laboratory phone: (415) 8491166 (Leave Message)
----------------------------------------------------------------------------
RESCROG(8L) MISC. REFERENCE MANUAL PAGES RESCROG(8L)
NAME
rescrog - change something, make it different
SYNOPSIS
/etc/rescrog [ system|service ] [ direction ]
DESCRIPTION
rescrog assumes the future basis of a system or service is
dependent on the analysis of bit patterns found on the sys-
tem device. It determines the logical next-best bit pattern
to yield the new system or service. This avoids the neces-
sity of distribution tapes.
Alterations are made by slight pseudo-random permutations by
recursive approximation based on the theory of the Towers of
Saigon, where the Oriental Guard could never play Ring-toss
twice on the same day.
rescrog's default direction is future (except for DoD-
installed systems, where the default is past). The first
argument tells rescrog whether to perform its actions on the
specified system or network service. It is best to rescrog
servers before clients in order to avoid out-of-phase
recovery errors.
FILES
/eunuchs
/dev/javu
/etc/etc
SEE ALSO
punt(1), spewtab(5), rescrogd(8)
BUGS
rescrog cannot distinguish between bugs and features.
Interruption while rescrogging can cause diddle-damage.
Repeated rescrogs done too quickly will lead to advanced
technology beyond our comprehension.
Roy Smith
Moving on from interesting man pages to interesting source code
comments, there is my all-time favorite, "you're not supposed to understand
this". Real wizards know where that's from.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
r...@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
Richard Wolff
>
> Moving on from interesting man pages to interesting source code
> comments, there is my all-time favorite, "you're not supposed to understand
> this". Real wizards know where that's from.
> --
slight correction: You are not expected to understand this.
--
Richard Wolff, National Optical Astronomy Observatories, Tucson, AZ
Internet: rwo...@noao.edu SPAN/HEPNET: draco::rwolff or 5355::rwolff
Usenet: {arizona,decvax,ncar}!noao!rwolff or uunet!noao.edu!rwolff
Phonenet: 602-325-9392
Roy Smith
In <1990Apr20....@noao.edu> rwo...@noao.edu (Richard Wolff) writes:
> slight correction: You are not expected to understand this.
I defer to a greater wizard. The change from supposed to expected
actualy does change the meaning rather a lot.
Steve Spicer
Smith) writes:
|>
|> In <1990Apr20....@phri.nyu.edu>, I wrote:
|> > "you're not supposed to understand this".
|>
|> In <1990Apr20....@noao.edu> rwo...@noao.edu (Richard Wolff) writes:
|> > slight correction: You are not expected to understand this.
|>
|> I defer to a greater wizard. The change from supposed to expected
|> actualy does change the meaning rather a lot.
|> --
Steven Spicer
spi...@apollo.hp.com
Mike McGaughey
cc++(1) Pyramid OSx Operating System cc++(1)
[...]
BUGS
This command should be called cc.
--
Mike McGaughey ACSNET: mm...@bruce.cs.monash.oz
"It's today!" said Piglet.
"My favorite day," said Pooh.
Luciano Mannucci
> Anyone on an HP 9000/800 running HP-UX 2.1 (and probably 3.1, 7.x etc)
> man tunefs
>
> Under the BUGS section it says (from memory)
>
> "You can tune a file system, but you can't tune a fish"
On HP 9000/835 running HP-UX 3.1 they moved the line above to the
WARNINGS section!
--
MODUS srl Via Aleardo Aleardi, 12 - 20154 Milano (Italy)
PHONE : +39 2 3315328 FAX: +39 2 3315778
E-MAIL: lu...@modus.sublink.ORG
--- Software & Services for Advertising & Marketing --------------------------
David Sherman|LSUC|Toronto
>> Under the BUGS section it says (from memory)
>>
>> "You can tune a file system, but you can't tune a fish"
>
>On HP 9000/835 running HP-UX 3.1 they moved the line above to the
>
>WARNINGS section!
More likely they did a global change of BUGS to WARNINGS (which
was never a Bell Labs standard manual heading), since most *documented*
UNIX bugs are probably more accurately called warnings anyway.
David Sherman
Toronto
--
Moderator, mail.yiddish
{ uunet!attcan att utzoo }!lsuc!dave da...@lsuc.on.ca
Andrew Cunningham
I've also seen:
BUGS
are nasty little things.
and
(for a x11/troff tool)
BUGS
This program should never have been written since it encourages
people to use troff instead of them converting to LaTeX
Gregory N. Bond
SUNVIEW(5) FILE FORMATS SUNVIEW(5)
NAME
sunview - initialization file for SunView
SYNOPSIS
~/.sunview
~/.suntools
/usr/lib/sunview
DESCRIPTION
To be supplied.
Sun Release 4.0 Last change: 2 September 1987 1
That one slipped past the keeper...
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: g...@melba.bby.oz.au non-MX: gnb%melba....@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
Martin Weitzel
>Many vendors (includingus, sadly) have been "professionalizing" these pages,
>which takes some of the fun out of unix.
No, it's only challenge for all authors to write the man page jokes in a
way that only other "gurus", but not the vendors can see it's a joke :-)
--
Martin Weitzel, email: mar...@mwtech.UUCP, voice: 49-(0)6151-6 56 83
Sandeep Mehta
>
>I've also seen:
>
>BUGS
>
> are nasty little things.
I remember one (unofficial one) from when I was TA-ing a junior level
programming course which required man pages to be submitted with the
assingment. the BUGS section of one student (with a sense of humor) went
something like:
BUGS
Are small little creatures that creep into programs. They need to be
exterminated. All such insects have been exterminated using [blah,
blah]...
I did get a laugh...
sandeep
--
s...@philabs.philips.com ...to be or not to bop ?
Bill Vermillion
And in an AT&T Sys V.2 (I think 0- about 5 years ago) I saw under
regxp
(A rather hazy quote)
"The source code for this is probably easier to understand than these manual
pages".
--
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
: bi...@bilver.UUCP
Matt Cohen
YES(1) USER COMMANDS YES(1)
NAME
yes - be repetitively affirmative
SYNOPSIS
yes [ expletive ]
DESCRIPTION
yes repeatedly outputs y, or if expletive is given, that is
output repeatedly. Termination is by typing an interrupt
character.
BUGS
Boring.
The "BUGS" was removed before 4.2BSD. Is "yes" any less boring in 4.X? :-)
Ever wonder what "yes" is good for?
(Answer 1: "yes | rm -i", etc. Answer 2: nothing.)
-- Matt
Matt Cohen UUCP: ...!uunet!chron!sysnmc
Department of Technology Resources AT&T: +1 713 220 7023
The Houston Chronicle FAX : +1 713 220 7722
801 Texas Avenue, Houston, TX 77002 "The opinions above are most likely
"Houston's Leading Information Source" those of my employer."
Mr N W Holloway
| Ever wonder what "yes" is good for?
I once needed an ascii file of a certain size (I can't remember why),
and used a combination of "yes" and "head".
$ yes 123456789abcdef | head -64 > 1K-file
Explanation: (15 chars + newline) * 64 = 1024
I don't want to read 101 other postings on how I could have done this
using UNIX tools - that is the wonder of UNIX, you can pick and choose
your tools for the job, and there is normally several ways of
performing a task. I just thought I'd share with you how I found a use
for "yes".
--
Nick Holloway | `O O' | al...@cs.warwick.ac.uk, al...@warwick.UUCP,
[aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!ukc!warwick!alfie
Roy Smith
It's also a reasonable way to generate a steady stream of characters
out a serial port (yes > /dev/tty?) so you can look at it with a scope, or
even over a network (yes | rsh otherhost dd of=/dev/null) so you can
generate tcpdump fodder.
Bruce Walker
This one came with Edition 6 PWB and detailed a command that took some
options and one argument, a process id that it would attempt to speed up.
The options controlled the number of lashes (if not specified, 17 would
be assumed, this being "the most random random number"), among other
things. Also, if no process was specified, it would print "flog you"
and exit.
I used to have a hard copy of this, but I seem to have misplaced it.
Does anyone out there have the complete text, and how about posting it
to alt.folklore.computers?
--
Bruce Walker ...uunet!utai!lsuc!isgtec!bmw b...@isgtec.uucp
"Remember Rule Number 79: When the tough get going, the weak get screwed."
ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8
Peter da Silva
while true
do echo ${*-y}
done
}
I'd much rather see 'echo' fixed, first.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
\_.--._/ Disclaimer: commercial solicitation by email to this address
v is acceptable.
P. Knoppers
>Does anyone remember a man page for a fictitious command called flog?
both joke manuals that cross-refer to each other). The manual for tm is
usually struck upon when trying to find out how to control the magtape
unit... These things are probably copyrighted. I will not post them
unless some informed person tells me that it is OK to do so.
--
_____ __ __ __ __ ____ _____ _____ ______ _____ _____
| _ \ | |/ || \| | / \ | _ \ | _ \ | ___|| _ \ / ___|
| __/ _ | < | || || || __/ | __/ | >__ | < \__ \
|__| |_| |__|\__||__|\__| \____/ |__| |__| |______||__|\__||_____/
P. Knoppers, Delft Univ. of Technology, The Netherlands, kn...@duteca.tudelft.nl
Peter Lamb
Section 2:
STATUS
FORK(2) currently is not supported by Digital Equipment Corporation
STATUS
EXIT(2) currently is not supported by Digital Equipment Corporation
All section 2 man pages had the same note. I believe this was done
by mistake. However, from the level of support we were getting here at the
time, it may as well have been true.
--
Peter Lamb
uucp: uunet!mcsun!ethz!prl eunet: p...@iis.ethz.ch Tel: +411 256 5241
Integrated Systems Laboratory
ETH-Zentrum, 8092 Zurich
Joshua Osborne
> It's also a reasonable way to generate a steady stream of characters
>out a serial port (yes > /dev/tty?) so you can look at it with a scope, or
>even over a network (yes | rsh otherhost dd of=/dev/null) so you can
>generate tcpdump fodder.
(i.e. no input, no stty'ing), and I didn't want it to exit, because I wanted
to see if it worked at all...
(turns out xterm works - as long as you don't use the csh that comes with
the DS3100, I'm working on that now...)
--
str...@eng.umd.edu "Security for Unix is like
Josh_Osborne@Real_World,The Mutitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
"Don't try to change C into some nice, safe, portable programming language
with all sharp edges removed, pick another language." - John Limpert
Kent Wilson
>b...@isgtec.UUCP (Bruce Walker) writes:
>Does anyone remember a man page for a fictitious command called flog?
>Does anyone out there have the complete text, and how about posting it...
FLOG(I) PWB/UNIX (4/1/77) FLOG(I)
NAME
flog - speed up a process
SYNOPSIS
flog [-ln] [-am] [-u] process-id
DESCRIPTION
Flog is used to stimulate an improvement in the performance
of a process that is already in execution.
The process-id is the process number of the process that is
to disciplined.
The value n of the l keyletter argument is the flagellation
constant, i.e, the number of lashes to be administered per
minute. If this argument is omitted, the default is 17,
which is the most random random number.
The value m of the a keyletter argument is the number of
times the inducement to speed up is to be administered. If
this argument is omitted, the default is one, which is based
on the possibility that after that, the process will rectify
its behavior of its own volition.
The presence of the u keyletter argument indicates that flog
is to be unmerciful in its actions. This nullifies the
effects of other keyletter arguments. It is recommended
that this option be used only on extremely stubborn
processes, as its over-use may have detrimental effects.
FILES
Flog will read the file /have/mercy for any entry containing
the process-id of the process being speeded-up. The file
can contain whatever supplications are deemed necessary,
but, of course, these will be totally ignored if the u
keyletter argument is supplied.
SEE ALSO
On Improving Process Performance by the Administration of
Corrective Stimulation, CACM, vol. 4, 1657, pp. 356-654
DIAGNOSTICS
If a named process does not exist, flog replies "flog you"
on the standard output. If flog kill(II)s the process,
which usually happens when the u keyletter argument is
supplied, it writes "rip", followed by the process-id of
the deceased on the standard output.
BUGS
Spurious supplications for mercy by the process being
flogged sometimes wind up on the standard output, rather
than in /shut/up.
Page 1 (printed 5/10/90)
Kent Wilson
GONG(I) PWB/UNIX (4/1/77) GONG(I)
NAME
gong - evaluate process performance
SYNOPSIS
gong [-f] [-a] process-id
DESCRIPTION
Gong is used to evaluate the performance of a process that
is in execution.
The process-id is the process number of the process whose
performance is to be evaluated.
The evaluation is performed by a set of three "panelist"
routines, each of which analyzes one aspect (time, space,
and tonality) of the performance of the process. If any of
these routines is not amused by the performance, the
process being analyzed is sent the gong(II) signal. In
addition, the process-id of the the evaluated process is
written on the standard gong, for possible future corrective
action. (It is suggested that the standard gong be an
audible alarm for proper effect.) It is expected that after
being gong(II)ed, the process will promptly commit suicide.
The f keyletter argument indicates that gong is to invoke
flog(I) with the unmerciful argument if the process does not
respond to gong(II)ing. In the absence of this argument,
the process is continuously gong(II)ed, which may lead to
the process becoming a deaf zombie.
The a keyletter argument indicates that if all three of the
panelist routines gong(II) a process, the process should be
unmercifully flog(I)ed whether on not the f keyletter is
supplied.
FILES
/dev/ding.dong is the standard gong.
SEE ALSO
On the Applicability of Gonging to the Performance and Merit
Review Process, Journal of Irreproducible Results, vol. 263,
issue 19, pp. 253-307. Stimulation, CACM, vol. 4, 1657, pp.
356-654
BUGS
If the named process does not exist, it is possible that
gong will attempt an evaluation of itself, which may lead to
a condition known as compounded double ringing (see
echo(I)). Therefor, it is recommended that gong be used
with extreme care.
Page 1 (printed 5/10/90)
Blair P. Houghton
>
>>b...@isgtec.UUCP (Bruce Walker) writes:
>>Does anyone remember a man page for a fictitious command called flog?
>
> flog - speed up a process
On most systems, in perfect Orwellian fashion, this command
is aliased to `renice'.
--Blair
"Complete with ambiguous
command-line option syntax."
Amoss Shapira
SEX(6) 32B Virtual Unix Programmer's Manual SEX(6)
NAME
sex - have sex
SYNOPSIS
sex [ options ] ... [ username ] ...
DESCRIPTION
sex allows the invoker to have sex with the user(s) speci-
fied in the command line. If no users are specified, they
are taken from the LOVERS environment variable. Options to
make things more interesting are as follows:
-1 masturbate
-a external stimulus (aphrodisiac) option
-b buggery
-B animal
bestiality with animal
-c chocolate sauce option
-C chaining option (cuffs included) (see also -m -s -W)
-d file
get a date with the features described in file
-e exhibitionism (image sent to all machines on the net)
-f foreplay option
-i coitus interruptus (messy!)
-j jacuzzi option (California sites only)
-l leather option
-m masochism (see -s)
-M triple parallel (Menage a Trois) option
-n necrophilia (if target process is not dead, program
kills it)
-o oral option
-O parallel access (orgy)
-p debug option (proposition only)
-P pedophilia (must specify a child process)
- 1 -
SEX(6) 32B Virtual Unix Programmer's Manual SEX(6)
-q quickie (wham, bam, thank you, ma'am)
-s sadism (target must set -m)
-S sundae option
-v voyeurism (surveys the entire net)
-w whipped cream option
-W whips (see also -s, -C, and -m)
ENVIRONMENT
LOVERS
is a list of default partners which will be used if
none are specified in the command line. If any are
specified, the values in LOVERS is ignored.
FILES
/usr/lib/sex/animals
animals for bestiality
/usr/lib/sex/blackbook
possible dates
/usr/lib/sex/sundaes
sundae recipes
/usr/lib/sex/s&m
sado-masochistic equipment
BUGS
^C (quit process) may leave the user very unsatisfied.
^Z (stop process) is usually quite messy.
MAN AUTHOUR
Sean Philip Engelson (spe@cad) at Carnegie-Mellon University
HISTORY
Oldest program ever.
- 2 -
Dan Kogai
>SEX(6) 32B Virtual Unix Programmer's Manual SEX(6)
Is this the one that comes w/ emacs?
>NAME
> sex - have sex
> -1 masturbate
That should've been any positive integer. My favorite option is
3 P. It takes opposite sex of uid as default but you can specify each
partner's sex with "+" option. When "+" option is set it takes "-num"
option as number of opposite sex partner and + with the same. Default
is -1 +1.
> -a external stimulus (aphrodisiac) option
Don't forget this program is our favorite program yet oldest so
it's constantly updated. We are testing and don't forget following
option:
-A AZT option for virul protection. still buggy.
> -C chaining option (cuffs included) (see also -m -s -W)
Recently this option is replace to condom option. Without argument
it takes default brand from .sexrc and with argument it takes it as a brand.
> -d file
> get a date with the features described in file
In addition to it it reads .sexrc when startup. you can suppress
.sexrc with -q option (see below)
> -e exhibitionism (image sent to all machines on the net)
This one now takes argument which is a file containing hosts.
default value is /etc/hosts but it can understand .newsrc so this is becoming
very common option.
> -f foreplay option
This option is very recommended because 9 out of 10 times sex(1)
fails without this option. Add foreplay(1) in .sexrc!
> -m masochism (see -s)
This option now can be set together with -s option. You can specify
who's gonna take -m or -s with "+" option. "+" plus option forces partner(s)
to take part (i.e -m +s)
> -M triple parallel (Menage a Trois) option
Now this option is now merged to "-3". see "-1".
> -n necrophilia (if target process is not dead, program
> kills it)
You need to have bluebeard(8) deamon to kill the target process
if it's alive.
> -o oral option
-a anal option. Old version has different meaning but now -a is
restored for anal option due to demand.
> -O parallel access (orgy)
Same thing can be done with -(n > 3) option now.
> -p debug option (proposition only)
This option works only when you have clinic(1) installed.
> -P pedophilia (must specify a child process)
new version takes login shell process as default. See -I option
for detail
-I Incest option: All process with same gid are partners.
> -q quickie (wham, bam, thank you, ma'am)
New version can set time before end of process. Value is
nanosecond.
> -s sadism (target must set -m)
> -v voyeurism (surveys the entire net)
This option requres tom(8) deamon.
-R Rape option. You need root access to take advantage of
this option.
-r random option. Useful when you sex(1) with frequent partner.
>ENVIRONMENT
> LOVERS
> is a list of default partners which will be used if
> none are specified in the command line. If any are
> specified, the values in LOVERS is ignored.
On new version LOVERS is ignored only when -dj option is set
(Dear John. not equivalent to -d -j). LOVERS are effective
for unset option.
>FILES
> /usr/lib/sex/animals
> animals for bestiality
>
> /usr/lib/sex/blackbook
> possible dates
Or ~/.blackbook for personalization. with -R option, you can use
other's .blackmail, too.
> /usr/lib/sex/sundaes
> sundae recipes
On new version it's /usr/lib/sex/food/sundaes because new version
has different version possible.
> /usr/lib/sex/s&m
> sado-masochistic equipment
On new version it's a directory that contains s&m equipment. intel
is one of the most popular today.
~/.sexrc
/usr/lib/sex/sex.rc
Always read when startup. If nonexistant, it reads
/usr/lib/sex/sex.rc. This can be suppressed with -q option.
/usr/lib/sex/contraceptive/*
Contains contraceptive deamons. Otherwise sex(8) causes
unexpected child process. -N (No baby) option automatically
chooses most effective one but no one of them are perfect yet
(See bugs)
>BUGS
> ^C (quit process) may leave the user very unsatisfied.
> ^Z (stop process) is usually quite messy.
This bug could be suppressed with stty -cbreak. Not torelant with
AIDS(8).
>MAN AUTHOUR
> Sean Philip Engelson (spe@cad) at Carnegie-Mellon University
Modification by Dan Kogai da...@ocf.berkeley.edu.
at University of California, Berkeley.
>HISTORY
> Oldest program ever.
Yet most frequently used and might be most dangerous program to use
due to AIDS deamons developped. -A option is still not perfect but this
option is only one approved by FDA (Fuckin' Dick Association). Don't forget
"-C brand" option (Condom and brand). Safe hex!
---
################## Dan The "I grok therefore I am God" Man
+ ____ __ __ + (Aka Dan Kogai)
+ ||__||__| + E-mail: da...@ocf.berkeley.edu
+ ____| ______ + Voice: 415-549-6111
+ | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709
+ |___ |__|__| + U.S.A
+ |____|____ + Disclaimer: I'd rather be blackmailed for my long .sig
+ \_| | + than give up my cool name in Kanji. And my
+ <- THE MAN -> + citizenship of People's Republic o' Berkeley
################## has nothing 2 do w/ whatever I post, ThanQ.
Amos Shapira
> this option.
Which reminds me:
"Super users do it without asking for permission."
Amos Shapira,
am...@batata.huji.ac.il.bitnet
Grey Fox
> > -R Rape option. You need root access to take advantage of
> > this option.
>
> Which reminds me:
>
> "Super users do it without asking for permission."
And since quite a few Universities have unix systems...
Doug Gwyn
>> > -R Rape option. You need root access to take advantage of
>> > this option.
>> Which reminds me:
>> "Super users do it without asking for permission."
Children, rape is not humorous.
Could you cut this out, please?
There is no end to the possibilities for silly manual pages.
This thread started out mentioning the humor in GENUINE manual pages
then degenerated into fantasy. There must be other places for that..
Stephen Clamage
>There is no end to the possibilities for silly manual pages.
>This thread started out mentioning the humor in GENUINE manual pages
>then degenerated into fantasy. There must be other places for that..
Hear, hear! I recommend /dev/null.
--
Steve Clamage, TauMetric Corp, st...@taumet.com
bra...@uicsl.csl.uiuc.edu
/* Written 3:20 pm May 19, 1990 by steve@taumetCOM in uicsl.csl.uiuc.edu:comp.unix.wizards */
/* End of text from uicsl.csl.uiuc.edu:comp.unix.wizards */
bra...@uicsl.csl.uiuc.edu
/* Written 3:20 pm May 19, 1990 by steve@taumetCOM in uicsl.csl.uiuc.edu:comp.unix.wizards */
>In article <12...@smoke.BRL.MIL> gw...@smoke.BRL.MIL (Doug Gwyn) writes:
>>There is no end to the possibilities for silly manual pages.
>>This thread started out mentioning the humor in GENUINE manual pages
>>then degenerated into fantasy. There must be other places for that..
>
>Hear, hear! I recommend /dev/null.
>--
>
>Steve Clamage, TauMetric Corp, st...@taumet.com
Lighten up, Francis; no one was discussing the moral implications of rape, or
any other issue; that is for another newsgroup. Besides, I never understand
what bothers you people; can't you hit the space bar, or whatever your
option is to proceed with the next post?? I'm sure the poster implied no
malice toward women.
(Gee, wonder how many flames I'll get on this one...)
Brando
+-----------------------------------------------------------------------------+
| Brandon Brown | Internet: bra...@uicsl.csl.uiuc.edu |
| Coordinated Science Laboratory | UUCP: uiucuxc!addamax!brando!brown |
| University of Illinois | CompuServe: 73040,447 |
| Urbana, IL 61801 | GEnie: macbrando |
+-----------------------------------------------------------------------------+
Dan KoGai
I'm the original author of this option and I think someone made me
pay for the price. Here's a copy of mail I mailed to root, et al, about
what happened to me!
---Begin copy---
Having finished CS 60 C final, I happily logged in my OCF account
and found something funny--seems like my .cshrc and other configure files
are not read at all. I typed in ls immediately and found nothing but
a sigle file. "Bozo" it's named. That was absolutely the only file
I found. I added -a option to see them all and got nothing. Nothing
but the following. Please take a look.
Don't you hate it when you leave your password in a .netrc in
a directory of stuff you ftp'ed over from the web. I sure do.
Then anyone can just get your password and delete all of your
files in both accounts. Bummer.
Some guy.
I immediately rlogged on my web account, c60c-3cf, only to find
that same thing happend.
This "Some guy" said that he got my password from .netrc but if
it's real, it's a big problem: Because what that mean is that the guy
had a root access--ftp won't work with .netrc with false mode. It must
be readable only by user and so I set. Or, a root user can read it as
well as all other files.
The date stamp of "Bozo" was 16:18 today, May 16 on OCF and 16:19
on WEB. Unfortunately I forgot last login message (I think it was from
violet so I didn't care at the first moment) so I cannot tell when the guy
got rid of everything I had on my accounts. But guys left a lot of clues:
He left a "Bozo" message that implies that he got my password from my .netrc.
He said "anyone". Not anyone can read my .netrc with mode 600, or
-rx-------. Only root users can do it. I hate it but I can only conclude
the villain is one of (or even ones of, maybe) OCF staff.
That crime was done very throughly. Not only did he get rid of all
"normal" files but also all dot files. Not only did he get rid of all I
had on OCF, but also all I had on web, including my homeworks and projects.
if he is just a root user of OCF there's no way he could delete my WEB files.
but he got it anyhow and the only source that's possible is my .netrc.
and only I and root user can read it--I never leaked my password to anybody.
This is the biggest desaster I encountered in Berkeley and could
be the biggest scandal in OCF history. I hate to say this but something
must be done to this. I have been infamous for disk hogger but still it
doesn't justify killing my dot files as well. Sorry for my typo and clumzy
writing--it was hard just to spell out words. Thanks for your concern.
---End of mail---
A few mails later, one of secutity guys found that one doesn't need
to read|write|execute files witout autorization in some occasions. .netrc
was obvously my mistake but I was thinking UNIX was secure enough. According
to him both Apollo Domain 10.1 (dankg@ocf) and SunOS 3.5 had some problem
in system secutiry. I don't know what to trust now. So here's my correction
of -R option:
-R rape option. root access is recommended but not needed
for some of the O.S. (ask your system administrator about it)
----------------
____ __ __ + Dan The "Raped" Man
||__||__| + E-mail: da...@ocf.berkeley.edu
____| ______ + Voice: +1 415-549-6111
| |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A
|___ |__|__| +
|____|____ + "What's the biggest U.S. export to Japan?"
\_| | + "Bullshit. It makes the best fertilizer for their rice"
Michael Crawford
Berkeley 4.3 has:
NAME
crash - what happens when a VAX kernel crashes
DESCRIPTION
This section explains what happens when the system crashes
and (very briefly) how to analyze crash dumps.
When the system crashes voluntarily it prints a message of
the form
panic: why i gave up the ghost
on the console, takes a dump on a mass storage peripheral,
and then invokes an automatic reboot procedure as described
in reboot(8). (If auto-reboot is disabled on the front
Now I would swear that under some rev of SunOS, the "takes a dump"
was replaced with something more polite, but under 4.0.3, it says
that again! Maybe it got snuck back in.
System 5.2 tee(1) says:
NAME
tee - pipe fitting
but SunOS 4.0.3 says:
NAME
tee - replicate the standard output
I am divided on the issue of professionalization of manual pages. I do
support it in the case that it makes manual pages clearer. An
unsophisticated user perusing the man pages might be a little mystified
why a plumbing device was documented in the Unix Manual.
Have any marketing types tried to do anything to take daemonology out
of the system? I imagine there may be countries that would not accept
Unix because they don't like invoking daemons.
--
Michael D. Crawford
Oddball Enterprises Consulting for Apple Computer Inc.
606 Modesto Avenue esc...@apple.com
Santa Cruz, CA 95060 Applelink: esc...@apple.com@INTERNET#
oddball!mi...@ucscc.ucsc.edu The opinions expressed here are solely my own.
alias make '/bin/make & rn'
Peter da Silva
> Have any marketing types tried to do anything to take daemonology out
> of the system? I imagine there may be countries that would not accept
> Unix because they don't like invoking daemons.
That's OK. Users don't generally invoke daemons. Daemons are usually
invoked by other daemons, all the way back to init. Just don't sign
anything in blood, and watch out for mode 666 files.
--
`-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.ferranti.com>
'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
@FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
Scott Barman
>
>NAME
> tee - pipe fitting
>
>but SunOS 4.0.3 says:
>
>NAME
> tee - replicate the standard output
>
>I am divided on the issue of professionalization of manual pages. I do
>support it in the case that it makes manual pages clearer. An
>unsophisticated user perusing the man pages might be a little mystified
>why a plumbing device was documented in the Unix Manual.
The System V definition of tee is historical. It was intended to be a
"pipe fitting" condering what its function is.
What you have to understand is that those wonderful folks at Sun have
systematically gone through and changed not only the traditional
descriptions on the man pages (like the above), but also those
wonderful error messages that has lived in Unix lore since many of us
got our hands on V7 (see the error messages from make(1) for a prime
example of this--on SunOS >4.0 type "make war" and watch what it
says!).
In addition to error message, Sun continues to move things around to
the point they it is getting real annoying. Like /usr/spool being a
symlink to /var/spool? Why not just keep /usr/spool as it has always
been? Another one would be to load SunOS 4.* and cd to /usr/lib/uucp
and not find everything there because THEY decided the configuration
stuff belongs in /etc/uucp after it has live in /usr/lib/uucp for all
these
I apologize to those not interested in a flame against Sun, but as a
user (and shareholder) I am very annoyed at these seemingly minor
changes that build up into one big horror!!!
Hey Sun: if it ain't broke DON'T FIX IT!!!!!!
--
scott barman NBC Systems Development
sc...@nbc1.ge.com 30 Rockerfeller Plaza, Room 1615W
{philabs,crdgw1}!nbc1!scott New York, NY 10112 +1 212/664-2787
(This does not represent any [un]official opinions of NBC or their affiliates)
Ed Anselmo
Scott> In addition to error message, Sun continues to move things around to
Scott> the point they it is getting real annoying. Like /usr/spool being a
Scott> symlink to /var/spool? Why not just keep /usr/spool as it has always
Scott> been? Another one would be to load SunOS 4.* and cd to /usr/lib/uucp
Scott> and not find everything there because THEY decided the configuration
Scott> stuff belongs in /etc/uucp after it has live in /usr/lib/uucp for all
Scott> these
I like having a /usr partition that doesn't grow. One less partition
to backup.
If you've ever tried sharing /usr/lib/uucp (with config files in
/usr/lib/uucp) across nfs partitions, you end up doing symlink tricks
anyway, so it's just as well that Sun moved the config files to
/etc/uucp.
Most of the old paths still work (/usr/man, /usr/spool, /usr/adm), so
most users don't notice the change.
--
Ed Anselmo ansel...@cs.yale.edu {harvard,decvax}!yale!anselmo-ed
Norman Yarvin
>Most of the old paths still work (/usr/man, /usr/spool, /usr/adm), so
>most users don't notice the change.
Until they do something like
%ls -l /usr/include | more
lrwxrwxrwx 1 root 19 May 31 10:00 /usr/include -> /server/usr/include/
%
and then have to try again with /server/usr/include.
It's no big deal, but these things add up. With 590 symbolic links in /usr,
and 24 NFS mounts, learning where things are becomes like trying to find
your way around in Adventure. Once you've found a file, you have to decide
which is the officially sanctioned path (i.e. the path that's not going to
disappear tomorrow). It just occurred to me to check $PATH for
redundancies; it turns out that /bin is redundant. It's a symbolic link to
/usr/bin.
Norman Yarvin yarvin...@cs.yale.edu
"Obviously crime pays, or there'd be no crime." -- G. Gordon Liddy
Guy Harris
>Until they do something like
>
>%ls -l /usr/include | more
>lrwxrwxrwx 1 root 19 May 31 10:00 /usr/include -> /server/usr/include/
>%
>
>and then have to try again with /server/usr/include.
Who's "they"? Sun sure didn't do anything like that, at least not in
4.0[.x]; "/usr/include" is just a boring old directory.
Ed Anselmo
>%ls -l /usr/include | more
>lrwxrwxrwx 1 root 19 May 31 10:00 /usr/include -> /server/usr/include/
>%
>
>and then have to try again with /server/usr/include.
Guy> Who's "they"? Sun sure didn't do anything like that, at least
Guy> not in 4.0[.x]; "/usr/include" is just a boring old directory.
'Twas the honest, loyal, trustworthy and under-appreciated Yale CS
computing facility that inflicted that upon the local community.
Seems the powers that be wanted 32MB of swap, 30MB of home
directories, plus / and /usr, all on a 105MB internal drive on a SS-1.
Well, it wasn't meant to be, and we had to play symlink games in /usr
to get "most" things to fit and have the rest symlinked to a server
directory.
John Chambers
> support it in the case that it makes manual pages clearer. An
> unsophisticated user perusing the man pages might be a little mystified
> why a plumbing device was documented in the Unix Manual.
>
> Have any marketing types tried to do anything to take daemonology out
> of the system? I imagine there may be countries that would not accept
> Unix because they don't like invoking daemons.
Even worse, they've done things like replacing the BUGS section with
euphemisms like RESTRICTIONS or QUALIFICATIONS. I remember 'way back
when, when I first stumbled across Unix; I was tremendously impressed
to see BUGS in bold letters on the pages. I decided that any system
whose manuals were so honest was well worth learning more about...
[more lines to satisfy the line counter ;-]
--
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
Doug Gwyn
>I apologize to those not interested in a flame against Sun, but as a
>user (and shareholder) I am very annoyed at these seemingly minor
>changes that build up into one big horror!!!
While I too am annoyed by some of these changes (mostly by the requirement
for /usr to be mounted to do anything even in single-user mode), Sun did
not make the changes for the user or the shareholder; they were made for
the system administrator and OS designer. The main considerations were
explained in the SunOS 4.0 documentation, which you should read and
understand before complaining further. (Basically, the design is
constrained by the properties of what my officemate calls the "dickless
workstation" environment; filesystems are partitioned functionally based
on whether they are read-only system support vs. read-write user files,
architecture-dependent vs. architecture-independent, workstation-specific
vs. shared, etc.)
Robert Landsparger
>man page for reboot:
>
>..skipping some...
>
>OPTIONS
> -d Dump ..etc...
>
> -n Avoid the sync(1). It can be used if a disk or the
> processor is on fire.
>
>...rest of man page....
Excuse me, but can someone tell me why you would want to reboot if the
machine was on fire? Always trying to learn something new! I guess if
the drive head didn't sync and didn't pass through the flames and the
"boot" area was not engulfed in fire, the machine might come back up.
I don't know...
Bob Landsparger
Jonathan I. Kamens
Landsparger) writes:
|> Excuse me, but can someone tell me why you would want to reboot if the
|> machine was on fire? Always trying to learn something new! I guess if
|> the drive head didn't sync and didn't pass through the flames and the
|> "boot" area was not engulfed in fire, the machine might come back up.
|> I don't know...
Well, I can't say anything about the processor being on fire, but
there *are* situations when you want to reboot without the sync. For
example, if fsck discovers problems with your root filesystem and tells
you to reboot immediately, you want to prevent the sync on reboot,
because the sync may write out to disk information which has just been
fixed by fsck, thus breaking it again. Therefore, when rebooting in
this situation you use the -n flag to reboot.
Or, at least, so I've been told. Somebody please tell me if this
isn't really the case :-).
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
j...@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
Charles Hedrick
commercializing Unix means removing any signs of life. However I do
not appreciate humor when it takes the place of useful information. I
suppose whoever wrote the reboot man page figured there was no
situation where -n was useful, so he made it into a joke:
> -n Avoid the sync(1). It can be used if a disk or the
> processor is on fire.
However there's a very real need for -n. It might be sensible to
mention it in the man page. If fsck finds a problem on root (or /usr
for SunOS), it is necessary to reboot the system without doing a sync.
If you did the sync, you might undo the repair done by fsck. Thus
/etc/rc (rc.boot for SunOS) uses reboot -n in that situation.
Another similar situation is /usr/ucb/whoami's infamous error message
"Intruder alert". I'm sure someone thought this was very cute, but
now and then misconfigured systems do trigger this error, and it would
be really friendly if whoami said something to help lead one in the
direction of finding the problem. In fact "Intruder alert" means that
whoami was unable to find your uid in /etc/passwd (or the YP system
for SunOS). Typically it means /etc/passwd is missing or protected
wrong, or that there is some problem with YP.
Scott Barman
>>>>>> On 8 Jun 90 16:26:56 GMT, sc...@nbc1.ge.com (Scott Barman) said:
>
>Scott> In addition to error message, Sun continues to move things around to
>Scott> the point they it is getting real annoying. Like /usr/spool being a
>Scott> symlink to /var/spool? Why not just keep /usr/spool as it has always
>Scott> been? Another one would be to load SunOS 4.* and cd to /usr/lib/uucp
>Scott> and not find everything there because THEY decided the configuration
>Scott> stuff belongs in /etc/uucp after it has live in /usr/lib/uucp for all
>Scott> these
>
>I like having a /usr partition that doesn't grow. One less partition
>to backup.
I never ran into this problem... I always tried to make sure "growing"
file systems were mounted. /usr/spool would be mounted from elsewhere,
for example.
>If you've ever tried sharing /usr/lib/uucp (with config files in
>/usr/lib/uucp) across nfs partitions, you end up doing symlink tricks
>anyway, so it's just as well that Sun moved the config files to
>/etc/uucp.
I don't know about you, but we have one machine, one exit point to the
outside world. All our sendmail.cf files are set up to pass mail
to the uucp server. What is in that directory is of no consequence
to the clients since they never execute uucp/uux. I like having one
machine to do uucp, it keeps life managable!
>Most of the old paths still work (/usr/man, /usr/spool, /usr/adm), so
>most users don't notice the change.
Let's try this senario: the tape(s) are delivered and you go over the
installation procedure in the manual and as part of the release notes
you are told the new system has HoneyDanBer UUCP. You think that's
great because it was the only thing you like when you had to live on
a System V box. You install your operating system and you go to setup
uucp. Having previous knowledge of HDB you immediatly cd to /usr/lib/uucp
and wonder where's the Permissions, Systems, Dialers, etc. files? I
had to waste my time (I am not a full-time administrator) and RTFM to
not only find out that the files are under /etc/uucp, but even with
the symlink in /usr/spool, I have to specify /var/spool/uucp* in the
permissions file or nothing will work right!
You're right, users do not notice the change. But I am not a full time
systems administrator and I have better things to do (including meeting
deadlines) than to hunt down things that have been in a "standard"
place since I learned Unix under v7. I still would like to know the
motivation!
Bob Goudreau
In article <1990Jun12.1...@nbc1.ge.com>, sc...@nbc1.ge.com
(Scott Barman) writes:
>>>
>>>In addition to error message, Sun continues to move things around to
>
>
> You're right, users do not notice the change. But I am not a full time
> systems administrator and I have better things to do (including meeting
> deadlines) than to hunt down things that have been in a "standard"
> place since I learned Unix under v7. I still would like to know the
> motivation!
Actually, the motivation is fairly reasonable, and the implementation
makes a lot of sense. Files and directories weren't moved gratuitously,
but only in pursuit of specific goals.
The most important capability gained by reorganizing files in this
manner is the ability to save disk space and make release management
easier by sharing most of the OS release files among multiple hosts.
In particular, a server machine and all its diskless clients can mount
the same /usr file system (the clients mount it read-only over NFS, in
fact) with no need to give each host its own copy. The important
dichotomy here is "shared & read-only" versus "private & read-write".
Shared stuff was moved to /usr; the (much smaller) set of private files
and directories that distinguish the "personality" of one system from
another were grouped together in the root (mostly in /etc and /var).
Under this setup, adding a new diskless client doesn't cost much disk
space on the server, since the only *new* space he needs is for his
own root and swap.
To give a concrete example of the differences between shared-RO data
and unshared-RW data, consider lpr and uucp. The actual *programs*
used for printing and for uucp communication stay in /usr (because
they're shareable); actual print jobs and uucp messages are private to
a particular system, so they belong in /var/spool. Likewise,
/usr/etc/termcap is shareable; /etc/motd is not. Of course, symlinks
can be used liberally to ease the transition. Just remember that
while many hosts may share the same symlink, the *target* of that
symlink is usually host-dependent. For example, several diskless
clients can mount the same /usr and thus share the same /usr/spool
symlink, but the target of that link (/var/spool) will differ
depending on which host the pathname is getting resolved on -- each
host gets its *own* /var/spool.
------------------------------------------------------------------------
Bob Goudreau +1 919 248 6231
Data General Corporation
62 Alexander Drive goud...@dg-rtp.dg.com
Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau
USA