Users often post questions with their full shell scripts pasted, asking "Why isn't it working"? In many of those cases, there isn't just a single bug in the script but several small issues (example). Most of the bugs in their scripts could be considered as "duplicates" since there are already specific similar questions for each issue, but the users don't know there are different problems. From his perspective there is one problem - the script doesn't run as expected. Again, see my comments for the question. Also, we cannot flag it with multiple duplicates (different users could flag with different duplicates, but one person cannot flag with multiple duplicates).

Anyway, sometimes one of those small issues in the script actually doesn't have a specific duplicate, but still the other problems in the script are.

If the user is lucky, someone would write down a detailed answer with all of the bugs, syntax errors and possible corner cases in their scripts. But usually those questions have no benefit for the site - just for the person who posted the question.

Some might argue that maybe those questions should be closed based on "lack of focus", but I think it will just confuse the users that posted the questions that won't know how to follow.

What is our approach for those questions? My thought is, ideally there will be some guidelines for submitting those types of questions, that would explain first how they should start debugging and troubleshooting their scripts themselves (instead of turning to this site as a "scripts troubleshooting service"). For instance (just from the top of my head):

  1. Use shellcheck first
  2. Run script with -x to see which commands run
  3. Try to isolate the problem and find the exact place where the script fails
  4. Split long single command lines to shorter one to isolate possible issues
  5. Add echo lines before specific lines to check the values of different variables
  6. Maybe some "common pitfalls" for bash scripting such as double/single quotes, word splitting etc. Maybe even add links to few questions that are "top hitters" that have good answers.

Any I'm sure there are others. But that's just one idea. What do you think?

  • 4
    I like the idea from StackOverflow of a minimal reproducible example. Suggest to the author that they reduce the script until the problem goes away, then reintroduce one element. SO's focus on coding seems relevant for a U&L question that is just one big shell script.
    – Jeff Schaller Mod
    Commented Jan 31 at 19:09
  • 2
    Ideally, they would never write a script to completion before testing it for the first time. Apart from knowing and using correct syntax, running the script to ensure every little incremental addition to it does what you think it does is often helpful (this in turn means that you always keep the script runnable, without unclosed loops or other unclosed control structures). But this has to do with the methodology of programming in general than specifically "shell scripting".
    – Kusalananda Mod
    Commented Jan 31 at 20:42
  • Ideally, it might be useful to have such instructions on what (and why!) to do before posting. But, does it matter what we think is ideal? Do you expect SE would be at all interested in implementing such features? Maybe if you could sell them an AI to do it. (And IMO, some post in meta doesn't help, the people writing those questions won't see it before posting.)
    – ilkkachu
    Commented Feb 2 at 11:10
  • I would use "Needs more focus". There are many issues in the script. Rework the question such that if focus in a single issue.
    – Braiam
    Commented Feb 14 at 19:02

1 Answer 1


Two things strike me with this:

  • I find it hard to help those who won't help themselves.
  • This is a Q&A, not a generic forum

That said, I always try to be helpful to an individual who come's seeking help.

My response to such questions would usually fall into one of two categories:

If the OP is asking a specific question about a specific bug in their code and that bug can be traced to a couple of mistakes then just get on and answer the question. Maybe make a note that there are other mistakes in their code, but not deliberately try to fix every bug, just the one questioned.

If the OP is just saying "this doesn't work" and fixing it means fixing multiple errors (4 or more?) then offer some comments suggesting they break it down, direct them to documentation on debugging, refer them to sscce.org, or even how to ask questions the smart way. But also let them know they are not really asking a question. It's better to give them a very good description of why they're not getting the help they wanted than just slam close the question with no feedback.

I'd be very cautious about a vote to close for this, but this is perhaps a good use of a custom reason. The "lack of focus" / "too broad" reasons are unlikely to let them know why the question was closed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .