schaker@hydra.unm.edu (Schakerianitisadium) (04/12/90)
Here are two humorous manual pages that only this audience
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 \ schaker@hydra.unm.edu, schaker@unmb.bitnet
| \___/ |
\_____/ Have a nice day... SOMEWHERE ELSE.tonys@pyrltd.UUCP (Tony Shaughnessy) (04/12/90)
In article <2281@ariel.unm.edu> schaker@hydra.unm.edu (Schakerianitisadium) writes: >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 tonys@pyra.co.uk
mike@ames.arc.nasa.gov (Mike Smithwick) (04/12/90)
In article <2281@ariel.unm.edu> schaker@hydra.unm.edu (Schakerianitisadium) writes: >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]
robert@jive.sybase.com (Robert Garvey) (04/13/90)
From the SunOS (and BSD) man page on spell:
BUGS
British spelling was done by an American.
Robert Garvey Sybase, Inc
robert@sybase.com 6475 Christie Ave
{sun,lll-tis,pyramid,pacbell}!sybase!robert Emeryville, CA 94608guy@auspex.auspex.com (Guy Harris) (04/14/90)
>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....guy@auspex.auspex.com (Guy Harris) (04/14/90)
>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" (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"....
prl@ethz.UUCP (Peter Lamb) (05/03/90)
My personal all-time favorites come from the Ultrix 1.0 man pages, 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: prl@iis.ethz.ch Tel: +411 256 5241 Integrated Systems Laboratory ETH-Zentrum, 8092 Zurich
stripes@eng.umd.edu (Joshua Osborne) (05/04/90)
In article <1990Apr30.144542.17928@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: > 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. It also came in handy when I was testing xterm, I didn't want anything fancy (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...) -- stripes@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
escher@Apple.COM (Michael Crawford) (06/07/90)
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 escher@apple.com
Santa Cruz, CA 95060 Applelink: escher@apple.com@INTERNET#
oddball!mike@ucscc.ucsc.edu The opinions expressed here are solely my own.
alias make '/bin/make & rn'peter@ficc.ferranti.com (Peter da Silva) (06/08/90)
In article <8591@goofy.Apple.COM> escher@Apple.COM (Michael Crawford) writes: > 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. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
scott@nbc1.ge.com (Scott Barman) (06/08/90)
In article <8591@goofy.Apple.COM> escher@Apple.COM (Michael Crawford) writes: >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. 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 scott@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)
Anselmo-Ed@cs.yale.edu (Ed Anselmo) (06/09/90)
>>>>> On 8 Jun 90 16:26:56 GMT, scott@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.
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 anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-edyarvin-norman@CS.Yale.EDU (Norman Yarvin) (06/10/90)
Anselmo-Ed@cs.yale.edu (Ed Anselmo) writes: >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-norman@cs.yale.edu "Obviously crime pays, or there'd be no crime." -- G. Gordon Liddy
guy@auspex.auspex.com (Guy Harris) (06/12/90)
>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.
Anselmo-Ed@cs.yale.edu (Ed Anselmo) (06/12/90)
>>>>> On 11 Jun 90 21:33:13 GMT, guy@auspex.auspex.com (Guy Harris) said: >%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. -- Ed Anselmo anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-ed
jc@minya.UUCP (John Chambers) (06/12/90)
> 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. 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.
REL@MTUS5.BITNET (Robert Landsparger) (06/12/90)
At least this man entry was not changed in the "up-grading": >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
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/12/90)
In article <1990Jun8.162656.14993@nbc1.ge.com> scott@nbc1.UUCP (Scott Barman) writes: >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.)
scott@nbc1.ge.com (Scott Barman) (06/12/90)
In article <ANSELMO-ED.90Jun9095657@bigbird.cs.yale.edu> Anselmo-Ed@cs.yale.edu (Ed Anselmo) writes: >>>>>> On 8 Jun 90 16:26:56 GMT, scott@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! -- scott barman NBC Systems Development scott@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)
hedrick@aramis.rutgers.edu (Charles Hedrick) (06/13/90)
I like the man pages to show some humor, and I oppose the concept that 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.
jik@athena.mit.edu (Jonathan I. Kamens) (06/13/90)
In article <90163.011455REL@MTUS5.BITNET>, REL@MTUS5.BITNET (Robert 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 jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (06/14/90)
In article <1990Jun12.145231.25545@nbc1.ge.com>, scott@nbc1.ge.com (Scott Barman) writes: >>> >>>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 > >... > > 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 goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA