Welcome to our site! Interesting questions and answers about UNIX & Linux are what this site is all about.

Let’s get some basics out of the way; skip ahead if you’ve already covered these.

1. **Register an account** - New users sometimes skip past the sign-up page and post as a guest. If you register your account, you’ll have an easier time editing your own post with updates and clarifications, commenting on your question, and commenting on Answers to your question.
2. **Take our tour** - Take a minute and read through our [tour page](https://unix.stackexchange.com/tour). It’s a quick introduction to the site (and to Stack Exchange) and it earns you a badge! If you’ve been to other Stack Exchange sites already, it will look familiar. Pay particular attention to the section that’s unique to UNIX & Linux, the "Ask about…" and "Don’t ask about" section.
3. **Browse the help pages** - Right at the end of the tour, there’s a link to our [Help Center](https://unix.stackexchange.com/help); there’s a lot to read there, so poke around the links that you find interesting. Since you’re interested in asking a good question, pay particular attention to these:

* [What topics can I ask about here?](https://unix.stackexchange.com/help/on-topic)
* [What types of questions should I avoid asking?](https://unix.stackexchange.com/help/dont-ask)
* [What does it mean if a question is "closed" or "on hold"?](https://unix.stackexchange.com/help/closed-questions)
* [How do I ask a good question?](https://unix.stackexchange.com/help/how-to-ask)
* [What are tags, and how should I use them?](https://unix.stackexchange.com/help/tagging)

Next, see if your question already has an answer. You might have searched this site directly or via a search engine, so skip ahead if you feel confident that you have a unique problem. There are over 100,000 questions on the site, though, so it doesn’t hurt to double-check!

1. Write down the main verbs and nouns from your problem in the [Ask a Question](https://unix.stackexchange.com/questions/ask) title box. You have no intention of submitting this as your question, yet. As you start typing, a list of *Questions that may already have your answer* will appear directly below the title field.
Let the search engine automatically show you questions that it thinks are similar. Open any of them separately to see if they pertain to your situation.
Take note of any questions that look as if they would solve your problem, but do not, for one reason or another; you might refer back to them in your question and explain why they do not solve your problem. This will prevent well-meaning reviewers from finding them and proposing your question as a duplicate of those.

2. If very few search results came back, look back at the [on-topic page](https://unix.stackexchange.com/help/on-topic) to confirm that your problem fits the on-topic list. If your question is not on-topic for the site, it may be closed for being “off-topic”. On the other hand, you may have a unique situation or combination of technology that hasn’t been asked about yet.

Before we continue, let’s avoid three very common pitfalls that result in questions being closed:

* opinion-based, or
* too broad, or
* unclear

Are you asking for people’s experiences with a certain piece of hardware or software? Are you wondering *if* something will work? Are you looking for guidance, or for opinions on how to proceed? If so, stop and re-think your approach. Questions should have concrete answers; instead of the “best” way to do something, are you actually concerned about limiting memory use, or network traffic? Do you need something that’s cross-platform?

Are you asking for an architectural-level solution? Something a consultant might be paid to spend several weeks on? You should have made some attempt at solving your problem; share those commands and any specific error messages or confusion before asking a question; otherwise, your question risks being closed as “too broad”.

Lastly, take a step back from your problem and ask yourself: “What would an answer look like?” Your question should give enough guidance about what’s specifically needed and what’s specifically excluded so that you don’t have to constantly guide answerers towards the solution that you *actually* need. Think of your question as if you had to explain it to an intelligent friend; even if they didn’t know what “grep” was, could they understand what you were trying to accomplish? If potential answerers (or reviewers) can’t figure out what you mean, and you don’t step in to clarify, your question risks being closed as “unclear what you’re asking”. If you have textual input, don’t provide it in a graphic! That’s a pitfall that’s become common enough to warrant its own [PSA](https://unix.meta.stackexchange.com/questions/4086/psa-please-dont-post-images-of-text).

Yet another way trap to avoid is to ask what’s known as an [“XY problem”](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). Keep your eyes on the goal; mention the things you tried and the errors you received, but be flexible if your approach isn’t the one that others take.

If you’re not sure what an objective, specific, and clear question might look like, you could do worse than to browse the [top-voted questions](https://unix.stackexchange.com/questions?sort=votes) or [top-viewed questions](https://unix.stackexchange.com/questions?sort=frequent). Many of those “top” questions rose there because of their canonical nature, and so generated many views and votes; they may very well be broader in scope than your question. To get a more targeted list of questions, head over to the [tags](https://unix.stackexchange.com/tags) page and enter some key words from your question, one at a time. When you find a matching tag, click on it to get a list of questions with that tag, then sort the questions by “Frequent” or by “Votes” to see what well-received questions in that tag look like.

Now let’s begin formulating your question. Go to (or stay at) the [tags](https://unix.stackexchange.com/tags) page and take the major nouns from your question and find at least one, but no more than five, tags that relate to your question. Tags are one of the two elements of your question that active users of the site will see first when looking for questions that they want to answer, so choose the ones that appear most pertinent to your question.

Now write a first draft of your question, either directly in the [Ask a Question](https://unix.stackexchange.com/questions/ask) form or in your favorite editor. Set up each of three sections:

* The title: create a sentence from your nouns & verbs that indicate the pertinent software, operating environment, goal, and any errors. You have a limit of 150 characters; this translates to approximately 20-25 average English words.

* The body: start with an outline of: a re-worded summary of your goal and operating environment; representative (sample) input and output; any commands that you tried in pursuit of your goal and their output/results.

* The tags: from the previous step

Now take another look at the body, particularly at the first 200 characters. This can be a third preview of your question beyond the title and tags, depending on the particular “view” a person takes while browsing the site. Rewrite the introduction to put as much of a “hook” as you can into the first 200 characters. This should describe the problem and the surprising result you got instead of the expected result. Think of a person who’s knowledgeable in this area; how would you get them engaged with your problem in one or two sentences?

Be thorough and pertinent in the body of your question; explain what you think you know, up to the edge of where you were surprised or stumped. Be as clear as you can in describing any translation between input and output. If possible, demonstrate how people can set up similar environments for them to test their potential solutions. **Show the research that you’ve already done**. As you already saw in [How do I ask a good question?](https://unix.stackexchange.com/help/how-to-ask), tell us what you’ve already found and why it didn’t meet your needs. Another method that was experimented with on Stack Overflow is a [question template](https://meta.stackoverflow.com/questions/363051/ask-a-question-template-v1-experiment-results), so if the following questions help you to frame yours, use them!

* What are you trying to accomplish?
* What is some sample input, if applicable.
* What would be the desired output, based on that input?
* What happened instead? Include any errors, verbatim.

Take one more look at your question’s title and body. Have you presented the question as well as you can? Before posting the Question, particularly if English is not your strong suit, run a spell checker on the title and body. Many browsers will underline words that they think are misspelled. Capitalize proper nouns such as “I” and “Linux”. Feel free to ask for help in the Unix & Linux chat room or even with a post on [English Language Learners](https://ell.stackexchange.com/). Make sure you have an actual question in your Question! It would end with a question mark and should act as the entry point for any answers.

Now – finally – **post your question!**

But you’re not done! Stay tuned to the site after posting for as long as you can, in case there are immediate requests for clarification. The active users of the site may read your question and enter comments requesting clarification. If they do ask for clarification, respond by editing your question using the “edit” link towards the bottom of your question – assuming you registered your account – DO NOT clarify your question in the comments! Comments do not support all the formatting options and may be deleted or collapsed together, all of which make it harder than it needs to be to piece together the correct question.

Finally, while you’re waiting, it’d be a good time to read [What should I do when someone answers my question?](https://unix.stackexchange.com/help/someone-answers). The main point is to up-vote (if you’ve earned that privilege, at 15 reputation points) and/or [accept](https://unix.stackexchange.com/help/accepted-answer) Answers that solve your problem. Do not feel any pressure to accept an answer immediately; it’s fine to do so, but it’s also OK to leave a question out there for a couple days to see if anyone else has other ideas or approaches to your problem.