Next: , Up: Invocation   [Contents][Index]


2.1 Starting the BASH debugger

Note: it is important to use a debugger-enabled bash. You will get an error message if the debugger is run under a version of BASH that does not have debugging support.

As mentioned above, one can enter the BASH debugger via Emacs or DDD. However you don’t have to use either of these. And these still need a way on their own to get things started.

There are in fact two other ways to start the BASH debugger. The first way is to pass the ‘--debugger’ option to bash with the name of your script the scripts arguments following that, or with a command string (-c).

bash --debugger script script-arguments...
bash --debugger -c command-string...

This calls a debugger initialization script. It works much like a BASH login profile which may set variables and define functions. But this shell profile is customized for debugging and as such arranges for itself to get called before each statement is executed. Although there are some problems at present in I/O redirection that the method described next doesn’t have, it is expected that over time more features will be enabled in bash when the ‘--debugger’ option is in effect.

The form ‘bash --debugger -c ...’ can be used to get into the debugger without having to give a script name to debug. Sometimes you may want to do this just to see how the debugger works: try some debugger commands or maybe get online help. If you run ddd --bash without giving a script name, it in fact uses this form.

In order for the ‘--debugger’ option to work however, you must have the debugger scripts installed in a place where the BASH debugger can find them. For this reason, in developing the BASH debugger, I use a second method more often; it doesn’t require the bash debugger to be installed. This method uses another script called bashdb which allows for giving its own options, the final option is signaled by adding --). After this, the name of the script to debugged and any the arguments to pass to that script are given. Using this method, one would start the debugger like this:

bash path-to-bashdb/bashdb bashdb-options -- script script-arguments...

If you don’t need to pass dash options to your program which might get confused with the debugger options, then you don’t need to add the --.2

As with the first method, bash should be a debugger-enabled bash. If bashdb has the path to bash in it at the top (e.g. via #!), and bashdb can be found in your program-search path, then this might be equivalent to the above:

bashdb bashdb-options -- script script-arguments...

There are two or three disadvantages however of running a debugger this way. First $0 will have the value bashdb rather than the script you are trying to run. For some scripts this may change the behavior of the debugged script. Second a traceback will contain additional lines showing the “source”-ing of the debugged script from bashdb. And third, although this way works better than the first method, over time this way may come into disuse.

An option that you’ll probably need to use if bashdb isn’t installed but run out of the source code directory is ‘-L’ which specifies the directory that contains the debugger script files.

You can further control how bashdb starts up by using command-line options. bashdb itself can remind you of the options available.

Type

bashdb -h

to display all available options and briefly describe their use.

When the bash debugger is invoked either by the bashdb front-end script or bash --debugging, the first argument that does not have an associated option flag for bashdb or bash (as the case may be) is used as the name a the script file to be debugged, and any following options get passed the debugged script.

Options for the bashdb front-end are shown in the following list.


Footnotes

(2)

And in the interest of full disclosure, although this was not shown in the example it is possible to add the -- after the script name to be debugged but before the first program option with a dash.


Next: , Up: Invocation   [Contents][Index]