home *** CD-ROM | disk | FTP | other *** search
/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / textfile / faqs / unix_faq / faq / part1 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  14.2 KB

  1. Xref: bloom-picayune.mit.edu comp.unix.questions:51334 comp.unix.shell:8340 news.answers:4776
  2. Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
  3. From: tmatimar@empress.com (Ted M A Timar)
  4. Newsgroups: comp.unix.questions,comp.unix.shell,news.answers
  5. Subject: Unix - Frequently Asked Questions (1/7) [Frequent posting]
  6. Supersedes: <unix-faq/faq/part1_723967331@athena.mit.edu>
  7. Followup-To: comp.unix.questions
  8. Date: 24 Dec 1992 06:03:11 GMT
  9. Organization: Empress Software
  10. Lines: 324
  11. Approved: news-answers-request@MIT.Edu
  12. Distribution: world
  13. Expires: 21 Jan 1993 06:02:09 GMT
  14. Message-ID: <unix-faq/faq/part1_725176929@athena.mit.edu>
  15. References: <unix-faq/faq/contents_725176929@athena.mit.edu>
  16. NNTP-Posting-Host: pit-manager.mit.edu
  17. X-Last-Updated: 1992/12/09
  18.  
  19. Archive-name: unix-faq/faq/part1
  20. Version: $Id: part1,v 2.1 92/12/04 07:43:43 tmatimar Exp $
  21.  
  22. These seven articles contain the answers to some Frequently Asked
  23. Questions often seen in comp.unix.questions and comp.unix.shell.
  24. Please don't ask these questions again, they've been answered plenty
  25. of times already - and please don't flame someone just because they may
  26. not have read this particular posting.  Thank you.
  27.  
  28. These articles are divided approximately as follows:
  29.  
  30.       1.*) General questions.
  31.       2.*) Relatively basic questions, likely to be asked by beginners.
  32.       3.*) Intermediate questions.
  33.       4.*) Advanced questions, likely to be asked by people who thought
  34.        they already knew all of the answers.
  35.       5.*) Questions pertaining to the various shells, and the differences.
  36.       6.*) An overview of Unix variants.
  37.       7.*) An comparison of configuration management systems (RCS, SCCS).
  38.  
  39. This article includes answers to:
  40.  
  41.       1.1)  Who helped you put this list together?
  42.       1.2)  When someone refers to 'rn(1)' or 'ctime(3)', what does
  43.               the number in parentheses mean?
  44.       1.3)  What does {some strange unix command name} stand for?
  45.       1.4)  How does the gateway between "comp.unix.questions" and the
  46.               "info-unix" mailing list work?
  47.       1.5)  What are some useful Unix or C books?
  48.       1.6)  What happened to the pronunciation list that used to be
  49.               part of this document?
  50.  
  51. If you're looking for the answer to, say, question 1.5, and want to skip
  52. everything else, you can search ahead for the regular expression "^1.5)".
  53.  
  54. While these are all legitimate questions, they seem to crop up in
  55. comp.unix.questions or comp.unix.shell on an annual basis, usually
  56. followed by plenty of replies (only some of which are correct) and then
  57. a period of griping about how the same questions keep coming up.  You
  58. may also like to read the monthly article "Answers to Frequently Asked
  59. Questions" in the newsgroup "news.announce.newusers", which will tell
  60. you what "UNIX" stands for.
  61.  
  62. With the variety of Unix systems in the world, it's hard to guarantee
  63. that these answers will work everywhere.  Read your local manual pages
  64. before trying anything suggested here.  If you have suggestions or
  65. corrections for any of these answers, please send them to to
  66. tmatimar@empress.com.
  67.  
  68. 1.1)  Who helped you put this list together?
  69.  
  70.       I took over the maintenance of this list.  Almost all of the work
  71.       (and the credit) for generating this compilation was done by
  72.       Steve Hayman.
  73.  
  74.       We also owe a great deal of thanks to dozens of Usenet readers who
  75.       submitted questions, answers, corrections and suggestions for this
  76.       list.  Special thanks go to Maarten Litmaath, Guy Harris and
  77.       Jonathan Kamens, who have all made many especially valuable
  78.       contributions.
  79.  
  80.       Part 5 of this document (shells) was written almost entirely by
  81.       Matthew Wicks <wicks@dcdmjw.fnal.gov>.
  82.  
  83.       Part 6 of this document (Unix flavours) was written almost entirely by
  84.       Pierre (P.) Lewis <lew@bnr.ca>.
  85.  
  86.       Where possible the author of each question and the date it was last
  87.       updated is given at the top.  Unfortunately, I only started this
  88.       practice recently, and much of the information is lost.  I was also
  89.       negligent in keeping track of who provided updates to questions.
  90.       Sorry to those who have made valuable contributions, but did not
  91.       receive the credit and recognition that they legitimately deserve.
  92.  
  93. 1.2)  When someone refers to 'rn(1)' or 'ctime(3)', what does
  94.       the number in parentheses mean?
  95.  
  96.       It looks like some sort of function call, but it isn't.  These
  97.       numbers refer to the section of the "Unix manual" where the
  98.       appropriate documentation can be found.  You could type "man 3
  99.       ctime" to look up the manual page for "ctime" in section 3 of
  100.       the manual.
  101.  
  102.       The traditional manual sections are:
  103.  
  104.     1    User-level  commands
  105.     2    System calls
  106.     3    Library functions
  107.     4    Devices and device drivers
  108.     5    File formats
  109.     6    Games
  110.     7    Various miscellaneous stuff - macro packages etc.
  111.     8    System maintenance and operation commands
  112.  
  113.       Some Unix versions use non-numeric section names.  For instance,
  114.       Xenix uses "C" for commands and "S" for functions.
  115.  
  116.       Each section has an introduction, which you can read with "man #
  117.       intro" where # is the section number.
  118.  
  119.       Sometimes the number is necessary to differentiate between a
  120.       command and a library routine or system call of the same name.
  121.       For instance, your system may have "time(1)", a manual page about
  122.       the 'time' command for timing programs, and also "time(3)", a
  123.       manual page about the 'time' subroutine for determining the
  124.       current time.  You can use "man 1 time" or "man 3 time" to
  125.       specify which "time" man page you're interested in.
  126.  
  127.       You'll often find other sections for local programs or even
  128.       subsections of the sections above - Ultrix has sections 3m, 3n,
  129.       3x and 3yp among others.
  130.  
  131. 1.3)  What does {some strange unix command name} stand for?
  132.  
  133.       awk = "Aho Weinberger and Kernighan"
  134.  
  135.     This language was named by its authors, Al Aho, Peter
  136.     Weinberger and Brian Kernighan.
  137.  
  138.       grep = "Global Regular Expression Print"
  139.  
  140.     grep comes from the ed command to print all lines matching a
  141.     certain pattern
  142.  
  143.             g/re/p
  144.  
  145.     where "re" is a "regular expression".
  146.  
  147.       fgrep = "Fixed GREP".
  148.  
  149.     fgrep searches for fixed strings only.  The "f" does not stand
  150.     for "fast" - in fact, "fgrep foobar *.c" is usually slower than
  151.     "egrep foobar *.c"  (Yes, this is kind of surprising. Try it.)
  152.  
  153.     Fgrep still has its uses though, and may be useful when searching
  154.     a file for a larger number of strings than egrep can handle.
  155.  
  156.       egrep = "Extended GREP"
  157.  
  158.     egrep uses fancier regular expressions than grep.  Many people
  159.     use egrep all the time, since it has some more sophisticated
  160.     internal algorithms than grep or fgrep, and is usually the
  161.     fastest of the three programs.
  162.  
  163.       cat = "CATenate"
  164.  
  165.     catenate is an obscure word meaning "to connect in a series",
  166.     which is what the "cat" command does to one or more files.  Not
  167.     to be confused with C/A/T, the Computer Aided Typesetter.
  168.  
  169.       gecos = "General Electric Comprehensive Operating System"
  170.     
  171.     When GE's large systems division was sold to Honeywell,
  172.     Honeywell dropped the "E" from "GECOS".
  173.  
  174.     Unix's password file has a "pw_gecos" field.  The name is a
  175.     real holdover from the early days.  Dennis Ritchie has reported:
  176.  
  177.         "Sometimes we sent printer output or batch jobs
  178.          to the GCOS machine.  The gcos field in the password file
  179.          was a place to stash the information for the $IDENT card.
  180.          Not elegant."
  181.  
  182.       nroff = "New ROFF"
  183.       troff = "Typesetter new ROFF"
  184.     
  185.     These are descendants of "roff", which was a re-implementation
  186.     of the Multics "runoff" program (a program that you'd use to
  187.     "run off" a good copy of a document).
  188.  
  189.       tee       = T
  190.  
  191.     From plumbing terminology for a T-shaped pipe splitter.
  192.  
  193.       bss = "Block Started by Symbol"
  194.     
  195.     Dennis Ritchie says:
  196.  
  197.         Actually the acronym (in the sense we took it up; it may
  198.         have other credible etymologies) is "Block Started by
  199.         Symbol." It was a pseudo-op in FAP (Fortran Assembly [-er?]
  200.         Program), an assembler for the IBM 704-709-7090-7094
  201.         machines.  It defined its label and set aside space for a
  202.         given number of words.  There was another pseudo-op, BES,
  203.         "Block Ended by Symbol" that did the same except that the
  204.         label was defined by the last assigned word + 1.  (On these
  205.         machines Fortran arrays were stored backwards in storage
  206.         and were 1-origin.)
  207.  
  208.         The usage is reasonably appropriate, because just as with
  209.         standard Unix loaders, the space assigned didn't have to be
  210.         punched literally into the object deck but was represented
  211.         by a count somewhere.
  212.  
  213.       biff = "BIFF"
  214.  
  215.     This command, which turns on asynchronous mail notification,
  216.     was actually named after a dog at Berkeley.
  217.  
  218.         I can confirm the origin of biff, if you're interested.
  219.         Biff was Heidi Stettner's dog, back when Heidi (and I, and
  220.         Bill Joy) were all grad students at U.C. Berkeley and the
  221.         early versions of BSD were being developed.   Biff was
  222.         popular among the residents of Evans Hall, and was known
  223.         for barking at the mailman, hence the name of the command.
  224.  
  225.     Confirmation courtesy of Eric Cooper, Carnegie Mellon University
  226.  
  227.       rc (as in ".cshrc" or "/etc/rc") = "RunCom"
  228.  
  229.     "rc" derives from "runcom", from the MIT CTSS system, ca. 1965.
  230.  
  231.         'There was a facility that would execute a bunch of
  232.         commands stored in a file; it was called "runcom" for "run
  233.         commands", and the file began to be called "a runcom."
  234.  
  235.         "rc" in Unix is a fossil from that usage.'
  236.     
  237.     Brian Kernighan & Dennis Ritchie, as told to Vicki Brown
  238.  
  239.     "rc" is also the name of the shell from the new Plan 9
  240.     operating system.
  241.  
  242.       Perl = "Practical Extraction and Report Language"
  243.  
  244.     The Perl language is Larry Wall's highly popular
  245.     freely-available completely portable text, process, and file
  246.     manipulation tool that bridges the gap between shell and C
  247.     programming (or between doing it on the command line and
  248.     pulling your hair out).  For further information, see the
  249.     Usenet newsgroup comp.lang.perl.
  250.  
  251.       Don Libes' book "Life with Unix" contains lots more of these
  252.       tidbits.
  253.  
  254. 1.4)  How does the gateway between "comp.unix.questions" and the
  255.       "info-unix" mailing list work?
  256.  
  257.       "info-unix" and "unix-qizards" are mailing list versions of
  258.       comp.unix.questions and comp.unix.wizards respectively.
  259.       There should be no difference in content between the
  260.       mailing list and the newsgroup.
  261.  
  262.       To get on or off either of these lists, send mail to
  263.       info-unix-request@brl.mil or unix-wizards-request@brl.mil.
  264.       Be sure to use the '-Request'.  Don't expect an immediate response.
  265.  
  266.       Here are the gory details, courtesy of the list's maintainer,
  267.       Bob Reschly.
  268.  
  269.       ==== postings to info-UNIX and UNIX-wizards lists ====
  270.  
  271.       Anything submitted to the list is posted; I do not moderate
  272.       incoming traffic -- BRL functions as a reflector.  Postings
  273.       submitted by Internet subscribers should be addressed to the list
  274.       address (info-UNIX or UNIX- wizards);  the '-request' addresses
  275.       are for correspondence with the list maintainer [me].  Postings
  276.       submitted by USENET readers should be addressed to the
  277.       appropriate news group (comp.unix.questions or
  278.       comp.unix.wizards).
  279.  
  280.       For Internet subscribers, received traffic will be of two types;
  281.       individual messages, and digests.  Traffic which comes to BRL
  282.       from the Internet and BITNET (via the BITNET-Internet gateway) is
  283.       immediately resent to all addressees on the mailing list.
  284.       Traffic originating on USENET is gathered up into digests which
  285.       are sent to all list members daily.
  286.  
  287.       BITNET traffic is much like Internet traffic.  The main
  288.       difference is that I maintain only one address for traffic
  289.       destined to all BITNET subscribers. That address points to a list
  290.       exploder which then sends copies to individual BITNET
  291.       subscribers.  This way only one copy of a given message has to
  292.       cross the BITNET-Internet gateway in either direction.
  293.  
  294.       USENET subscribers see only individual messages.  All messages
  295.       originating on the Internet side are forwarded to our USENET
  296.       machine.  They are then posted to the appropriate newsgroup.
  297.       Unfortunately, for gatewayed messages, the sender becomes
  298.       "news@brl-adm".  This is currently an unavoidable side-effect of
  299.       the software which performs the gateway function.
  300.  
  301.       As for readership, USENET has an extremely large readership - I
  302.       would guess several thousand hosts and tens of thousands of
  303.       readers.  The master list maintained here at BRL runs about two
  304.       hundred fifty entries with roughly ten percent of those being
  305.       local redistribution lists.  I don't have a good feel for the
  306.       size of the BITNET redistribution, but I would guess it is
  307.       roughly the same size and composition as the master list.
  308.       Traffic runs 150K to 400K bytes per list per week on average.
  309.  
  310. 1.5)  What are some useful Unix or C books?
  311.  
  312.       Mitch Wright (mitch@cirrus.com) maintains a useful list of Unix
  313.       and C books, with descriptions and some mini-reviews.  There are
  314.       currently 77 titles on his list.
  315.  
  316.       You can obtain a copy of this list by anonymous ftp from
  317.       ftp.wg.omron.co.jp (133.210.4.4), where it's
  318.       "pub/unix-faq/docs/Unix-C-Booklist".  If you can't use anonymous
  319.       ftp, email the line "help" to "mailserv@iuvax.cs.indiana.edu" for
  320.       instructions on retrieving things via email.
  321.  
  322.       Send additions or suggestions to mitch@cirrus.com.
  323.  
  324. 1.6)  What happened to the pronunciation list that used to be part of this
  325.       document?
  326.  
  327.       From its inception in 1989, this FAQ document included a
  328.       comprehensive pronunciation list maintained by Maarten Litmaath
  329.       (thanks, Maarten!).  (Does anyone know who *created* it?)
  330.  
  331.       It has been retired, since it is not really relevant to the topic
  332.       of "Unix questions".  You can still find it as part of the
  333.       widely-distributed "Jargon" file (maintained by Eric S. Raymond,
  334.       eric@snark.thyrsus.com) which seems like a much more appropriate
  335.       forum for the topic of "How do you pronounce  /* ?"
  336.  
  337.       If you'd like a copy, you can ftp one from ftp.wg.omron.co.jp
  338.       (133.210.4.4), it's "pub/unix-faq/docs/Pronunciation-Guide".
  339.  
  340. -- 
  341. Ted Timar - tmatimar@empress.com
  342. Empress Software, 3100 Steeles Ave E, Markham, Ont., Canada L3R 8T3
  343.