0

It seems to me (and correct me if I'm wrong please) that bash is quite bad at error messages that correctly tell you where the problem in your script is. For example, often I will get "bad EOF at line 953". What this really means is that there is a missing fi at line 127. Or, another classic is "-bash: line 60: syntax error near unexpected token '('". What this really means is that I have redeclared my function mything() {} as an alias at line 739 alias mything=, except that, the bash error points to line 60 where there is no actual problem (so it took me a while to find the culprit at line 739).

I tried to load the top hit 'bash debug' tool into VS Code and I was unable to get that to work (I press F5 to run, then a box appears saying "choose a debugger" so I select bash debug and nothing happens). I've tried an online tool that allows running code interactively and says that it can help with debugging, but that also did not help. I do some PowerShell and it does quite a bit better job at reporting the source of a problem. Are there ways (tools, or script analysis tools on github or online that can scan a script for issues like functions and aliases being redeclared with the same name and other tests like that) that enable us to debug bash scripts a bit better?

Improve this question
6
  • 3
    There's shellcheck, but as a general rule, if you have bash scripts that are hundreds of lines long you should almost certainly be using a proper programming language and not a shell. The shell isn't made for this sort of thing.
    – terdon ♦
    Commented Oct 5, 2021 at 21:28
  • Thanks for shellcheck. I don't do extended logic with bash, none of my functions are more than say 30 lines long. There is utility in bash being "always there" and being the interface that I interact with a system, so I've never bought into that whole "bash bashing philosophy" of saying that bash is not a "proper language"; it has a lot of utility. I use other languages too (python, powershell, c#). My 1,000+ line bash scripts are sets of useful day to day functions that I use frequently.
    – YorSubs
    Commented Oct 6, 2021 at 6:07
  • 1
    To me, needing a shell script debugger is something that implies you're doing debugging far too late in the process. It seems that employing an iterative way of writing shell scripts may be helpful to you. Don't expect to write a script that does what it's supposed to do, all at once. Instead, write an empty main loop and just make sure it iterates over the right things. Then add extraction of one piece of data, or whatever you need to do next, and make sure that bit works, testing after adding each new "feature" of the code.
    – Kusalananda ♦
    Commented Oct 6, 2021 at 9:56
  • I do all that, to the extent that I can, but over time, things happen, time constraints, jumping between projects. Unfortunately, "life happens", and things creep in, so debugging something is required in those situations.
    – YorSubs
    Commented Oct 6, 2021 at 11:26
  • The issues you are describing in the first paragraph are typical of all programming languages, e.g. C. A missing round bracket will cause an error to be thrown many lines of codes later.
    – dr_
    Commented Oct 6, 2021 at 12:39

1 Answer 1

Reset to default
1

I found this simple shell breakpoint-debugger in a german shell-scripting book. You add the two following lines where ever you want to start debugging and step through by pressing enter or evaulate variables and functions at runtime.

read var    # set simple breakpoint
echo -e "dbg> \c"; read cmd; eval $cmd

run script

$ dbg> doSomethingFunction
$ dbg> echo $SOME_VAR

Alternatively using set -x and modifying the prompt variable PS4 has helped me in the past.

PS4='+ ${BASH_SOURCE##*/}.${LINENO} ${FUNCNAME}: '
Improve this answer

You must log in to answer this question.

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