1. Bad Questions
When people approach others for advice or help in solving a problem, they often find they have a hard time getting the answer they are looking for.
In almost all cases, the cause for this is bad questions. Bad questions don't do anyone any good. It wastes your time, and it means people will be far less likely to even try to help you.
In your best interest, and that of the people willingly offering their advice and experience, here's a few examples of ways questions can go wrong, why they are bad, and how to reformulate them. That way, you will learn to get the correct answers to your questions quickly.
In fact, it is often the case that while giving some thought as to how to formulate your question correcty, many have even solved their own problem they could not solve before.
1.1. Lost in the details
After I grep for a word in a file, I need to delete that line and the next 4 lines. Any thoughts?
The problem here is that this person is trying to put together some of his knowledge to achieve a goal, but doesn't realize that what he knows doesn't actually apply. You cannot edit a file just from the output of a grep operation on it. You're not in the file, you just have a string of characters that represents a line of text that is copied from the file. The real answer here is to use a file editor, such as ed.
The person asking the question has, for whatever reason, become fixated on grep, to the extent that it's become part of the question. This blinds him to other possibilities that don't involve grep.
How do we reformulate this to get the correct answer?
I want to find a word in a file, and then delete that line and the next four lines from the file.
Why is this more correct? We actually formulate what we want, not how we think to solve it. When you have a problem, always express the problem, not your attempt at a solution. Your attempt at a solution failed; therefore, it is very likely that attempt at a solution was flawed. Basing your question on it will only mislead you and the people trying to help you.
1.2. Help me fix my solution to my problem
It's great when people have tried their best to solve their problems before coming for help. Only, it's important to realize that when you come for help, it's better to explain the real underlying issue you're trying to solve.
Many times, we get incredibly weird questions, asking for things that one should never want to do. Other times, it's quite apparent that the person is trying to solve a problem by means of an ugly workaround or hack. We can help you fix your hack, but that wouldn't be ideal. In almost all of these cases, solving the real problem is significantly easier and in the end, for the person with the problem, it is always the most helpful kind of help.
Annoyingly, this type of bad question is often only identified after interrogation. That's bad, because it means the person will only receive good help if the person helping him is willing to figure out what the real problem is. If nobody is helpful enough to do that, the person with the problem will just get really bad solutions to possibly trivial problems. Consider:
10:24| Milos | Can someone give me a good example of what I should use to encode something and be able to decode it? i.e. two-way encryption/decryption? 10:24| lhunath | coding or crypting? 10:24| lhunath | openssl probably. 10:25| Milos | lhunath, uh, well, no I think I phrased that wrong - I just want something so I can have "hello this has spaces and *2384" into something like 0938reksfoiur9owe8gi but to be able to decode it afterwards. 10:25| lhunath | purpose? 10:25| Milos | lhunath, passing args that might have spaces or special chars.
The real problem is related to using bash parameters to pass data to other programs. Properly quoting the parameters when used as arguments or passing the data in another safe way was the real solution. Encoding the argument data into something else is a horrid way of avoiding bash wordsplitting (instead of turning it off with quoting) and in this case, the person was injecting the data into another interpreter's code. Injecting data into code is always a really bad idea.
So remember: You can ask your question; but also explain your purpose. The real problem you're trying to solve or the actual thing you're trying to do. Explain it without using ANY implementation details; no bash, no pseudocode, just English.
1.3. Questions containing errors
<I440r> in /etc/bashrc how can i modify PROMPT_COMMAND so taht it does not truncate the display of PWD ?
When faced with a question like this, we can't even answer it, because it contains so many errors -- factual errors, conceptual errors -- that before we can even attempt to get to the root of the issue and provide help, we have to deconstruct an entirely erroneous worldview first.
This is frustrating for us, but it's often painful for the person asking the question. Nobody likes to face the fact that their entire perception of reality is wrong. This means that quite often any attempt to help the person is going to lead to flaming (usually in both directions), etc.
In fact, IRC is a very poor medium for addressing perceptual anomalies of this magnitude. One needs time and room to set forth a clear list of the errors, and to address each error separately. This can be done much more easily on a mailing list, or a web forum, or Usenet.
Using our example,
There is no /etc/bashrc file by default. If your OS vendor has provided one, it means they hacked up their version of Bash. Some vendors have chosen to do this, but you should not follow their trend. You should definitely not be adding things to an /etc/bashrc file (or /etc/bash.bashrc -- that is sometimes used as well) if you happen to find one. In fact, if something that's in an /etc/bashrc file is causing you grief, just delete it!
The larger issue with /etc/bashrc or similar files is that some people believe they know what's best for their users, and want to control the environment of their users. On the other hand, Unix believes that users know best what they want, and should have control of their own environment. The use of a centralized /etc/bashrc-type file is contrary to the spirit of Unix. ~/.bashrc contains extremely personal aliases and functions and settings. There is no reasonable justification for imposing one's personal choice of aliases (especially horrific abominations like alias rm='rm -i') on users en masse!
You generally do not want to use the PROMPT_COMMAND variable to display a prompt. You want to use PS1 instead. The contents of PS1 are displayed (with certain backslash sequences interpreted by Bash at that moment) every time Bash needs to show a prompt. PROMPT_COMMAND, on the other hand, is a set of commands (rather than things-to-show) that are executed right before PS1 is displayed. PROMPT_COMMAND can be used to set variables that PS1 will use, or to perform actions outside of the prompt.
Now, with those things in mind, one might be prepared to investigate what atrocity your OS vendor has committed and undo it. At the bare minimum, an investigator would need to know:
What is in the offending /etc/bashrc file.
What is in the offending PROMPT_COMMAND variable.
What is in the PS1 variable.
What you want your prompt to look like.
This is just one example. The problem of questions containing errors is quite prevalent and shows up extremely frequently.