home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / unix / unixq_1.txt < prev    next >
Encoding:
Internet Message Format  |  2003-06-11  |  8.8 KB

  1. Subject: Welcome to comp.unix.questions [Monthly posting]
  2.  
  3. [Last changed: $Date: 91/01/03 14:10:03 $ by $Author: sahayman $]
  4.  
  5.  
  6. Comp.unix.questions is one of the most popular and highest volume
  7. newsgroups on Usenet.  This article is a monthly attempt to remind
  8. potential posters about what is appropriate for this newsgroup.
  9. If you would like to make any suggestions about the
  10. content of this article, please contact its maintainer at
  11. sahayman@iuvax.cs.indiana.edu  or  iuvax!sahayman .
  12.  
  13. A companion article includes the answers to some Frequently
  14. Asked Questions.  You may save yourself a lot of time by reading
  15. that article before posting a question to the net.
  16.  
  17.  
  18. If you have not already read the overall Usenet introductory material
  19. posted to "news.announce.newusers", please do.  Much of this article
  20. overlaps with the common sense guidelines posted there.
  21.  
  22.  
  23.          Should I Post My Unix Question to the Net?
  24.  
  25. Often the answer is "No, you can get an answer a lot faster without
  26. posting a question." Before you post, you should try -
  27.     
  28.     o Reading the manual for your system.  Some day you may encounter
  29.       the phrase "RTFM", which stands for "Read the Fine Manual"
  30.       (except 'F' doesn't really stand for "Fine").  If you ask
  31.       someone a question and they tell you to RTFM, it's an
  32.       indication that you haven't done your homework.   For instance,
  33.       if you are having trouble removing a file whose name begins
  34.       with a "-", check the man page for "rm".  It might tell
  35.       you what you need to know.
  36.  
  37.       When people use terminology like "read(2)", they are referring
  38.       to the "read" man page in section 2 of the manual (which you 
  39.       would see by using "man 2 read").
  40.  
  41.     o Finding a knowledgeable user at your site.  Many sites have
  42.       at least a few Unix experts who will be happy to help you
  43.       figure out how to remove a file whose name begins with "-".
  44.       Many larger sites, particularly universities, may even have
  45.       paid consultants whose job is to help you with Unix problems.
  46.       Check with them first.
  47.     
  48.     o Find a good introductory book on Unix.  There are plenty of
  49.       such books available, and you will save yourself a lot
  50.       of trouble by having one handy and consulting it frequently.
  51.       (Question 30 in part 2 of this list will let you know where
  52.        you can find a list of good Unix and C books.)
  53.       
  54. Please remember that the comp.unix.* newsgroups are read by over 50,000
  55. people around the world, and that posting a question to this group will
  56. cost a lot of time and money by the time your article is distributed to
  57. Japan, Australia, Europe (including the Soviet Union), Africa, Israel,
  58. and all corners of North America.
  59.  
  60. Also, some people receive these newsgroups as part of a mailing list
  61. rather than a newsgroup.  If you're one of these people, please don't
  62. send a "Remove me from this list" or "UNSUBSCRIBE"  message to the
  63. wrong place.  Take the time to figure out where you're getting this
  64. stuff from, and send your request to the mailing list maintainer, *not*
  65. to the list or newsgroup itself!  Ask your local postmaster for help.
  66. (One of the answers in part 2 of this document deals with the
  67. details of the mailing list.)
  68.  
  69.  
  70.  
  71.                To Which Newsgroup Should I Post My Question?
  72.  
  73.  
  74. The choice of newsgroup is harder than it used to be.  In the old days,
  75. you just had to choose between "comp.unix.questions" and
  76. "comp.unix.wizards".  The latter group has been subdivided into several
  77. specific groups.   Choose one of the following groups carefully.  If
  78. you aren't sure where your question belongs or if your question is not
  79. specific to some particular version of Unix, try "comp.unix.questions".
  80. Many knowledgeable Unix wizards read that group and will be able
  81. to help you.
  82.  
  83. Here are the capsule descriptions of various groups you might consider
  84. (extracted from a monthly posting to "news.announce.newusers")
  85.  
  86. comp.unix.questions     UNIX neophytes group.
  87.             If your question isn't a really good match for one of
  88.             the groups below, post it here.
  89.  
  90. comp.lang.c             Discussion about C.
  91.  
  92. comp.sources.unix       Postings of complete, UNIX-oriented sources. (Moderated)
  93. comp.std.unix           Discussion for the P1003 committee on UNIX. (Moderated)
  94. comp.unix               Discussion of UNIX* features and bugs. (Moderated)
  95. comp.unix.admin         Administering a Unix-based system.
  96. comp.unix.aix           IBM's version of UNIX.
  97. comp.unix.aux           The version of UNIX for Apple Macintosh II computers.
  98. comp.unix.internals     Discussions on hacking UNIX internals.
  99. comp.unix.large         UNIX on mainframes and in large networks.
  100. comp.unix.misc          Various topics that don't fit other groups.
  101. comp.unix.msdos         MS-DOS running under UNIX by whatever means.
  102. comp.unix.programmer    Q&A for people programming under Unix.
  103. comp.unix.shell         Using and programming the Unix shell.
  104. comp.unix.sysv286       UNIX System V (not XENIX) on the '286.
  105. comp.unix.sysv386       Versions of Unix (not Xenix) on Intel 80386-based boxes.
  106. comp.unix.ultrix        Discussions about DEC's Ultrix.
  107. comp.unix.xenix.misc    General discussions regarding XENIX (except SCO).
  108. comp.unix.xenix.sco     XENIX versions from the Santa Cruz Operation.
  109.  
  110.           What Information Should I Include?
  111.  
  112. It's hard to include too much information.  There are hundreds of
  113. different Unix systems out there, and they all have less in common
  114. than you might think.  If you have a problem and are posting an
  115. article, please be sure to mention:
  116.  
  117.     o A descriptive subject line.  Many people will decide whether
  118.       to read your article solely on the basis of the subject line,
  119.       so it should be a good statement of your problem.
  120.  
  121.       NOT GOOD                          GOOD
  122.  
  123.       "Help"                            "How do I sort a file by line length?"
  124.       "Csh question"            "csh dumps core when I use '$<'"
  125.  
  126.  
  127.     o What computer you are using, and what specific version
  128.       of the operating system it uses.  For instance,
  129.  
  130.         SunOS 4.0.1, Sun 3/50
  131.         4.3BSD-tahoe, Vax 11/780
  132.         SVR3.2, 3b2
  133.  
  134.     o If possible, the *exact* text of any error message you
  135.       may have encountered.
  136.  
  137.       WRONG                RIGHT
  138.  
  139.       "I can't print this file"     "When I type 'lpr Filename', I get
  140.                       lpr: Filename: File too ugly to print
  141.                      What does this mean?  It isn't in
  142.                      the man page.  This is using
  143.                      Mueslix 9.3 on a Fax 68086502"
  144.  
  145. It's a good idea to post unrelated questions in separate articles,
  146. so that people can keep different discussions separate.   It's also 
  147. a *very* good idea to include a line or two like this:
  148.  
  149.     "Please mail your answers to me and I'll summarize what I get
  150.      and post the results to comp.unix.questions."
  151.  
  152. This prevents many identical responses from different users to the
  153. same question from clogging up the newsgroup.  And make sure
  154. you really summarize what you get - don't just concatenate
  155. all the mail you've received.
  156.  
  157. It's also a good idea to read comp.unix.questions for at least a couple
  158. of weeks after you post your article to see what followup articles
  159. are posted.
  160.  
  161.  
  162.                 Should I Post an Answer to a Question?
  163.  
  164. It's very tempting to post an answer to a question you read on the net,
  165. especially when you think "Aha, finally - a question I can answer!"
  166. Consider though that when a simple question is asked, such as the
  167. sort about to be answered below, many other people around the
  168. world already know the answer and may be posting their own reply.
  169. In order to avoid dozens of replies to simple questions, please
  170. wait a day or so and see if anyone else has already answered
  171. the question.  If you have something special to contribute, please
  172. do so, but make sure you're not duplicating something someone else has
  173. already done.
  174.  
  175. You should feel free to reply to any question >by email<.  Even if
  176. the user gets 200 responses to his question, at least the load on the
  177. rest of the net is minimized.
  178.  
  179.  
  180.                     What About Posting Source Code?
  181.  
  182. Posting small amounts of example code is fine (use comp.sources.unix to
  183. distribute complete programs) - but please make sure that your code
  184. runs (or at least compiles) properly.  Don't just type it in while
  185. editing your posting and hope it will work, no matter how sure you are
  186. that it will.  We all make mistakes.
  187.  
  188.  
  189.                         What About Those People
  190.        Who Continue to Ask Stupid or Frequently Asked Questions
  191.          In Spite of The Frequently Asked Questions Document?
  192.  
  193.  
  194. Just send them a polite mail message, possibly referring them to this document.
  195. There is no need to flame them on the net - it's busy enough as it is.
  196.  
  197. -- 
  198. Steve Hayman    Workstation Manager    Computer Science Department   Indiana U.
  199. sahayman@iuvax.cs.indiana.edu                                   (812) 855-6984
  200.