> Archive-name: unix-faq/unix/intro
> Version: $Id: intro,v 2.4 1995/03/28 14:13:34 tmatimar Exp $
> Comp.unix.questions is one of the most popular and highest volume
> newsgroups on Usenet. This article is a monthly attempt to remind
> potential posters about what is appropriate for this newsgroup.
> If you would like to make any suggestions about the content of
> this article, please contact its maintainer at
> tmati...@isgtec.com.
> Many FAQs, including this one, are available on the archive site
> rtfm.mit.edu in the directory pub/usenet/news.answers.
> The name under which a FAQ is archived appears in the "Archive-Name:"
> line at the top of the article. This FAQ is archived as
> "unix-faq/unix/intro".
> Companion articles include the answers to some Frequently
> Asked Questions. You may save yourself a lot of time by reading
> those articles before posting a question to the net.
> If you have not already read the overall Usenet introductory material
> posted to "news.announce.newusers", please do. Much of this article
> overlaps with the common sense guidelines posted there.
> Should I Post My Unix Question to the Net?
> Often the answer is "No, you can get an answer a lot faster without
> posting a question." Before you post, you should try -
> o Reading the manual for your system. Some day you may encounter
> the phrase "RTFM", which stands for "Read the Fine Manual"
> (except 'F' doesn't really stand for "Fine"). If you ask
> someone a question and they tell you to RTFM, it's an
> indication that you haven't done your homework. For instance,
> if you are having trouble removing a file whose name begins
> with a "-", check the man page for "rm". It might tell
> you what you need to know.
> When people use terminology like "read(2)", they are referring
> to the "read" man page in section 2 of the manual (which you
> would see by using "man 2 read").
> o Finding a knowledgeable user at your site. Many sites have
> at least a few Unix experts who will be happy to help you
> figure out how to remove a file whose name begins with "-".
> Many larger sites, particularly universities, may even have
> paid consultants whose job is to help you with Unix problems.
> Check with them first.
> o Find a good introductory book on Unix. There are plenty of
> such books available, and you will save yourself a lot
> of trouble by having one handy and consulting it frequently.
> (Question 1.5 in the companion articles will let you know
> where you can find a list of good Unix and C books.)
> Please remember that the comp.unix.* newsgroups are read by over 80,000
> people around the world, and that posting a question to this group will
> cost a lot of time and money by the time your article is distributed to
> Asia, Australia, Europe (west and east), Africa, the middle east,
> and all corners of North, South and Central America.
> Also, some people receive these newsgroups as part of a mailing list
> rather than a newsgroup. If you're one of these people, please don't
> send a "Remove me from this list" or "UNSUBSCRIBE" message to the
> wrong place. Take the time to figure out where you're getting this
> stuff from, and send your request to the mailing list maintainer, *not*
> to the list or newsgroup itself! Ask your local postmaster for help.
> (One of the answers in the companion articles deals with the details of
> the mailing list.)
> To Which Newsgroup Should I Post My Question?
> The choice of newsgroup is harder than it used to be. In the old days,
> you just had to choose between "comp.unix.questions" and
> "comp.unix.wizards". Now there are a variety of more specific groups.
> Choose one of the following groups carefully. If you aren't sure where
> your question belongs or if your question is not specific to some
> particular version of Unix, try "comp.unix.questions". Many
> knowledgeable Unix wizards read that group and will be able to help you.
> Here are the capsule descriptions of various groups you might consider
> (extracted from a monthly posting to "news.announce.newusers")
> comp.unix.questions General questions from UNIX users and sys admins.
> If your question isn't a really good match for one of
> the groups below, post it here.
> news.answers Repository for periodic USENET articles. (Moderated)
> This article is crossposted there.
> Do not try to post here unless you're
> posting a list of FAQ's and their answers.
> comp.unix.shell Using and programming any UNIX shell.
> comp.lang.c Discussion about C.
> comp.sources.unix Postings of complete, UNIX-oriented sources. (Moderated)
> comp.std.unix Discussion for the P1003 committee on UNIX. (Moderated)
> comp.unix.admin Administering a Unix-based system.
> comp.unix.aix IBM's version of UNIX.
> comp.unix.amiga Unix on the Commodore Amiga
> comp.unix.aux The version of UNIX for Apple Macintosh II computers.
> comp.unix.bsd Discussions relating to BSD UNIX.
> comp.unix.internals Discussions on hacking UNIX internals.
> comp.unix.large UNIX on mainframes and in large networks.
> comp.unix.misc Various topics that don't fit other groups.
> comp.unix.programmer Q&A for people programming under Unix.
> comp.unix.ultrix Discussions about DEC's Ultrix.
> comp.unix.xenix.misc General discussions regarding XENIX (except SCO).
> comp.unix.xenix.sco XENIX versions from the Santa Cruz Operation.
> comp.os.linux.* Discussion about Linux ...
> comp.lang.perl Discussion about Perl
> comp.unix.wizards In-depth discussions of advanced unix topics.
> People should not post to this group unless they
> have used unix as a user, sysadmin and know details
> of the kernel, and how different unix kernels differ.
> In other words, don't post to comp.unix.wizards.
> What Information Should I Include?
> It's hard to include too much information. There are hundreds of
> different Unix systems out there, and they all have less in common
> than you might think. If you have a problem and are posting an
> article, please be sure to mention:
> o A descriptive subject line. Many people will decide whether
> to read your article solely on the basis of the subject line,
> so it should be a good statement of your problem.
> NOT GOOD GOOD
> "Help" "How do I sort a file by line length?"
> "Csh question" "csh dumps core when I use '$<'"
> o What computer you are using, and what specific version
> of the operating system it uses. For instance,
> SunOS 4.0.1, Sun 3/50
> 4.3BSD-tahoe, Vax 11/780
> SVR3.2, 3b2
> o If possible, the *exact* text of any error message you
> may have encountered.
> WRONG RIGHT
> "I can't print this file" "When I type 'lpr Filename', I get
> lpr: Filename: File too ugly to print
> What does this mean? It isn't in
> the man page. This is using
> Mueslix 9.3 on a Fax 68086502"
> It's a good idea to post unrelated questions in separate articles,
> so that people can keep different discussions separate. It's also
> a *very* good idea to include a line or two like this:
> "Please mail your answers to me and I'll summarize what I get
> and post the results to comp.unix.questions."
> This prevents many identical responses from different users to the
> same question from clogging up the newsgroup. And make sure
> you really summarize what you get - don't just concatenate
> all the mail you've received.
> It's also a good idea to read comp.unix.questions for at least a couple
> of weeks after you post your article to see what followup articles
> are posted.
> Should I Post an Answer to a Question?
> It's very tempting to post an answer to a question you read on the net,
> especially when you think "Aha, finally - a question I can answer!"
> Consider though that when a simple question is asked, such as the
> sort about to be answered below, many other people around the
> world already know the answer and may be posting their own reply.
> In order to avoid dozens of replies to simple questions, please
> wait a day or so and see if anyone else has already answered
> the question. If you have something special to contribute, please
> do so, but make sure you're not duplicating something someone else has
> already done.
> You should feel free to reply to any question >by email<. Even if
> the user gets 200 responses to his question, at least the load on the
> rest of the net is minimized.
> What About Posting Source Code?
> Posting small amounts of example code is fine (use comp.sources.unix to
> distribute complete programs) - but please make sure that your code
> runs (or at least compiles) properly. Don't just type it in while
> editing your posting and hope it will work, no matter how sure you are
> that it will. We all make mistakes.
> What About Those People
> Who Continue to Ask Stupid or Frequently Asked Questions
> In Spite of The Frequently Asked Questions Document?
> Just send them a polite mail message, possibly referring them to this document.
> There is no need to flame them on the net - it's busy enough as it is.
> --
> Ted Timar - tmati...@isgtec.com
> ISG Technologies Inc, 6509 Airport Rd., Mississauga, Ont., Canada L4V 1S7