lotus



previous page: 172. If this Document Still Hasn't Answered Your Question....
  
page up: Linux FAQ
  
next page: 174. How To Email Someone about Your Problem

173. What to Put in a Request for Help




Description

This article is from the Frequently Asked Questions for Linux, the Free/Open Source UNIX-like operating system kernel that runs on many modern computer systems. Maintained by David C. Merrill with numerous contributions by others. (v1.0).

173. What to Put in a Request for Help

Please read the following advice carefully about how to write your posting or E-mail. Making a complete posting will greatly increase the chances that an expert or fellow user reading it will have enough information and motivation to reply.

This advice applies both to postings asking for advice and to personal E-mail sent to experts and fellow users.

Make sure you give full details of the problem, including:

*What program, exactly, you are having problems with. Include the version number if known and say where you got it. Many standard commands tell you their version number if you give them a --version option. *Which Linux release you're using (Red Hat, Slackware, Debian, or whatever) and what version of that release. *The exact and complete text of any error messages printed. *Exactly what behavior you expected, and exactly what behavior you observed. A transcript of an example session is a good way to show this. *The contents of any configuration files used by the program in question and any related programs. *What version of the kernel and shared libraries you have installed. The kernel version can be found by typing uname -a, and the shared library version by typing ls -l /lib/libc*. *Details of what hardware you're running on, if it seems appropriate.

You are in little danger of making your posting too long unless you include large chunks of source code or uuencoded files, so err on the side of giving too much information.

Use a clear, detailed Subject line. Don't put things like "doesn't work", "Linux", "help", or "question" in it ?? we already know that. Save the space for the name of the program, a fragment of an error message, or summary of the unusual behavior.

Put a summary paragraph at the top of your posting.

At the bottom of your posting, ask for responses by email and say you'll post a summary. Back this up by using Followup-To: poster. Then, actually post the summary in a few days or a week or so. Don't just concatenate the replies you received, summarize them. Putting the word "SUMMARY" in your summary's Subject line is also a good idea. Consider submitting the summary to news: comp.os.linux.announce.

Make sure your posting doesn't have an inappropriate References: header line. This marks your article as part of the thread of the article referred to, which will often cause it to be junked by readers, along with the rest of a boring thread.

You might like to say in your posting that you've read this FAQ and the appropriate HOWTO'sthis may make people less likely to skip your posting.

Remember that you should not post E-mail sent to you personally without the sender's permission.

 

Continue to:















TOP
previous page: 172. If this Document Still Hasn't Answered Your Question....
  
page up: Linux FAQ
  
next page: 174. How To Email Someone about Your Problem