You can use this manual at your leisure to read all about the BASH debugger. However, a handful of commands are enough to get started using the debugger. This chapter illustrates those commands.

Below we will debug a script that contains a function to compute the factorial of a number: fact(0) is 1 and fact(n) is n*fact(n-1).

$ bashdb -L .  /tmp/fact.sh
Bourne-Again Shell Debugger, release bash-4.2-0.8
Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2011 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(/tmp/fact.sh:9):
  9:	echo fact 0 is: `fact 0`
bashdb<0> -

  1:    #!/usr/local/bin/bash
  2:    fact() {
  3:    ((n==0)) && echo 1 && return
  4:    ((nm1=n-1))
  5:    ((result=n*`fact $nm1`))
  6:    echo $result
  7:    }
  8:    
  9:==> echo fact 0 is: `fact 0`
bashdb<1> list
 10:   echo fact 3 is: $(fact 3)

The command invocation uses the option “-L .” Here we assume that the bashdb script and the debugger files are in the same location. If you are running from the source code, this will be the case. However if bashdb has been installed this probably won’t be true and here you probably don’t need to use “-L .” Instead you would type simply bashdb /tmp/fact.sh.

Position information consists of a filename and line number, e.g. (/tmp/fact.sh:9) and is given parenthesis. This position format is similar to that used in a dozen or so other debuggers; GNU Emacs and DDD can parse this format.

In the first debugger command we gave -, we listed a window of lines before where we were executing. Because the window, 10 lines, is larger than the number of lines to the top of the file we printed only 9 lines here. The next command, list, starts from the current line and again wants to print 10 lines but because there are only one remaining line, that is what is printed.

bashdb<2> step

(/tmp/fact.sh:9):
fact 0
9:	echo fact 0 is: `fact 0`
bashdb<(3)> <RET>
2:	fact() {
bashdb<(4)> <RET>
3:	((n==0)) && echo 1 && return
bashdb<(5)> print $n

bashdb<(6)>

Ooops... The variable n isn’t initialized.(1)

The first step command steps the script one instruction. It may seem odd that the line printed is exactly the same one as before. What has happened though is that we’ve “stepped” into the subshell needed to run `fact 0`; we haven’t however started running anything inside that subshell yet though.

To indicate that which piece of the multi-part line echo fact 0 is: `fact 0` we show that part all by itself fact 0. If nothing is shown then it means we are running the beginning statement or in this case the outermost statement.

To indicate that we are now nested in a subshell, notice that the command number, starting with 3, or the third command entered, now appears in parenthesis. Each subshell nesting adds a set of parenthesis.

The first step command steps the script one instruction; it didn’t advance the line number, 9, at all. That is because we were stopping before the command substitution or backtick is to take place. The second command we entered was just hitting the return key; bashdb remembers that you entered step previously, so it runs the step rather than next, the other alternative when you hit <RET>. Step one more instruction and we are just before running the first statement of the function.

Next, we print the value of the variable n. Notice we need to add a preceding dollar simple to get the substitution or value of n. As we will see later, if the pe command were used this would not be necessary.

We now modify the file to add an assignment to local variable n and restart.

bashdb<6> restart

Restarting with: /usr/local/bin/bashdb -L . fact.sh
(/tmp/fact.sh:10):
10:	echo fact 0 is: `fact 0`
bashdb<0> list 1
  1:    #!/usr/local/bin/bash
  2:    fact() {
  3:    local -i n=${1:0}
  4:    ((n==0)) && echo 1 && return
  5:    ((nm1=n-1))
  6:    ((result=n*`fact $nm1`))
  7:    echo $result
  8:    }
  9:    
 10:==> echo fact 0 is: `fact 0`
bashdb<1> s 3

(/tmp/fact.sh:3):
3:	local -i n=${1:0}
bashdb<(2)> step
(/tmp/fact.sh:4):
4:	((n==0)) && echo 1 && return
bashdb<(3)> print $n
print $n
0

This time we use the list debugger command to list the lines in the file. From before we know it takes three step commands before we get into the fact() function, so we add a count onto the step command. Notice we abbreviate step with s; we could have done likewise and abbreviated list with l.

bashdb<(4)> <RET>
(/tmp/fact.sh:4):
4:	((n==0)) && echo 1 && return
echo 1
bashdb<(5)> <RET>
(/tmp/fact.sh:4): 
4:	((n==0)) && echo 1 && return
return

Again we just use <RET> to repeat the last step commands. And again the fact that we are staying on the same line 4 means that the next condition in the line is about to be executed. Notice that we see the command (echo 1 or return) listed when we stay on the same line which has multiple stopping points in it. Given the information above, we know that the value echo’ed on return will be 1.

bashdb<(6)> <RET>
fact 0 is: 1
(/tmp/fact.sh:12): 
12:	echo fact 3 is: $(fact 3)
bashdb<(7)> break 5
Breakpoint 1 set in file fact.sh, line 5.
bashdb<(8)> continue

We saw that we could step with a count into the function fact(). However above took another approach: we set a stopping point or “breakpoint” at line 5 to get us a little ways into the fact() subroutine. Just before line 5 is to executed, we will get back into the debugger. The continue command just resumes execution until the next stopping point which has been set up in some way.

(/tmp/fact.sh:5):
5:      ((nm1=n-1))
Breakpoint 1 hit(1 times).
bashdb<(8)> x n-1

2
bashdb<(9)> s
(/tmp/fact.sh:5):
6:     ((result=n*`fact $nm1`))
bashdb<(10)> c
fact.sh: line 6: ((: result=n*: syntax error: operand expected (error token is "*")
bashdb<(7)> R

Restarting with: bash --debugger fact.sh 
11:	echo fact 0 is: `fact 0`
bashdb<0> l fact
 2:    fact () 
 3:    { 
 4:       local -i n=${1:0};
 5:       (( "n==0" )) && echo 1 && return;
 6:       (( nm1=n-1 ));
 7:       ((fact_nm1=`fact $nm1`))
 8:       (( "result=n*fact_nm1" ));
 9:       echo $result
10:    }

In addition to listing by line numbers, we can also list giving a function name. Below, instead of setting a breakpoint at line 5 and running “continue” as we did above, we try something slightly shorter and slightly different. We give the line number on the “continue” statement. This is a little different in that a one-time break is made on line 5. Once that statement is reached the breakpoint is removed.

bashdb<1> continue 5

One-time breakpoint 1 set in file fact.sh, line 5.
fact 0 is: 1
(/tmp/fact.sh:5):
5:	((nm1=n-1))
bashdb<(2)> s
6:	((fact_nm1=`fact $nm1`))
bashdb<(3)> s
2:	fact() {
bashdb<(4)> T
->0 in file `fact.sh' at line 2
##1 fact("3") called from file `fact.sh' at line 12
##2 source("fact.sh") called from file `/usr/local/bin/bashdb' at line 154
##3 main("fact.sh") called from file `/usr/local/bin/bashdb' at line 0
bashdb<(5)> c

fact 3 is: 6
Debugged program terminated normally. Use q to quit or R to restart.

When we stop at line 5 above, we have already run fact(0) and output the correct results. The output from the program “fact 0 is: 1” is intermixed with the debugger output. The T command above requests call stack output and this confirms that we are not in the fact(0) call but in the fact(3) call. There are 4 lines listed in the stack trace even though there is just one call from the main program. The top line of the trace doesn’t really represent a call, it’s just where we currently are in the program. That last line is an artifact of invoking bash from the bashdb script rather than running bash --debugger.

The last message in the output above ‘Debugged program exited normally.’ is from the BASH debugger; it indicates script has finished executing. We can end our bashdb session with the quit command.

Above we did our debugging session on the command line. If you are a GNU Emacs user, you can do your debugging inside that. Also there is a(nother) GUI interface called DDD that supports the BASH debugger.

One of the things I had found disappointing about the default set -x tracing behavior is that no position information is given in the trace output, in particular the line number and the file name. However with the introduction in Bash 3.0 of the introspection variables, also needed to support the debugger, one can set $PS4 to rectify this. (I became of this in a defunct blog http://raz.cx/blog/2005/08/handy-bash-debugging-trick.html.)

Here’s what I use:

  PS4='(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]} - [${SHLVL},${BASH_SUBSHELL}, $?]
'

Note that the string is in single quotes, not double quotes and there is a newline in the string. By using single quotes, variables which have a dollar in front of them in the string are expanded in the current environment of the line that is about to be run rather than at the time the variable PS4 is set.

You might want to add this in your shell’s start-up script, e.g., .bashrc, or .profile.

There is also facility inside the bash debugger showing position information when tracing a script. Here’s a simple session.

/usr/local/bin/bashdb /tmp/fact.sh
Bourne-Again Shell Debugger, release bash-4.2-0.8
Copyright 2002, 2003, 2004, 2006, 2007, 2008 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(/tmp/fact.sh:11):
11:	echo fact 0 is: `fact 0`
bashdb<0> set linetrace on
bashdb<1> cont

(/tmp/fact.sh:11):
level 1, subshell 1, depth 0:	echo fact 0 is: `fact 0`
fact 0
(/tmp/fact.sh:2):
level 1, subshell 1, depth 1:	fact() {
(/tmp/fact.sh:3):
level 1, subshell 1, depth 1:	    local -i n=${1:0}
(/tmp/fact.sh:4):
level 1, subshell 1, depth 1:	    ((n==0)) && echo 1 && return
(/tmp/fact.sh:4):
level 1, subshell 1, depth 1:	    ((n==0)) && echo 1 && return
echo 1
(/tmp/fact.sh:4):
level 1, subshell 1, depth 1:	    ((n==0)) && echo 1 && return
return
fact 0 is: 1
(/tmp/fact.sh:13):
level 1, subshell 0, depth 0:	echo fact 3 is: $(fact 3)
(/tmp/fact.sh:13):
level 1, subshell 1, depth 0:	echo fact 3 is: $(fact 3)
fact 3
(/tmp/fact.sh:2):
level 1, subshell 1, depth 1:	fact() {
(/tmp/fact.sh:3):
level 1, subshell 1, depth 1:	    local -i n=${1:0}
(/tmp/fact.sh:4):
level 1, subshell 1, depth 1:	    ((n==0)) && echo 1 && return
(/tmp/fact.sh:5):
level 1, subshell 1, depth 1:	    ((nm1=n-1))
(/tmp/fact.sh:6):
level 1, subshell 1, depth 1:	    ((fact_nm1=`fact $nm1`))
(/tmp/fact.sh:6):
level 1, subshell 2, depth 1:	    ((fact_nm1=`fact $nm1`))
fact $nm1
(/tmp/fact.sh:2):
level 1, subshell 2, depth 2:	fact() {
...
level 1, subshell 4, depth 4:	fact() {
(/tmp/fact.sh:3):
level 1, subshell 4, depth 4:	    local -i n=${1:}
(/tmp/fact.sh:4):
level 1, subshell 4, depth 4:	    ((n==0)) && echo 1 && return
(/tmp/fact.sh:4):
level 1, subshell 4, depth 4:	    ((n==0)) && echo 1 && return
echo 1
(/tmp/fact.sh:4):
level 1, subshell 4, depth 4:	    ((n==0)) && echo 1 && return
return
(/tmp/fact.sh:7):
level 1, subshell 3, depth 3:	    ((result=n*fact_nm1))
(/tmp/fact.sh:8):
level 1, subshell 3, depth 3:	    echo $result
(/tmp/fact.sh:7):
level 1, subshell 2, depth 2:	    ((result=n*fact_nm1))
(/tmp/fact.sh:8):
level 1, subshell 2, depth 2:	    echo $result
(/tmp/fact.sh:7):
level 1, subshell 1, depth 1:	    ((result=n*fact_nm1))
(/tmp/fact.sh:8):
level 1, subshell 1, depth 1:	    echo $result
fact 3 is: 6
(/usr/local/bin/bashdb:260):
level 1, subshell 0, depth -1:	
Debugged program terminated normally. Use q to quit or R to restart.
bashdb<2> 

An explanation of the output. The level is how many invocations of BASH are in effect before the statement shown is executed. The subshell is how many subshells you are nested in. Subshells are used by command substitution—`..' and $(...)—as well as arithmetic expressions ((...)). The depth is the function depth or how many calls you are nested in. A “source” command also increases this depth.

Notice also that in contrast to set -x tracing, the line shown is exactly as you entered it in the source. So if you indented statements in a meaningful way, it will help you understand the statement nesting level. But as before, if a line contains multiple statements, you are not executing the first statement in the line and set showcommand is not turned off (by default it is on), that statement is shown in addition below the multi-statement line. Such an example can be seen right at the beginning where fact 0 is shown.

If what you want to do is trace the entire script as was done above (and not stop in the debugger when the script is over), you can get the same effect by using the -X or --trace option on the bashdb command:

/usr/local/bin/bashdb -X /tmp/fact.sh
Bourne-Again Shell Debugger, release bash-4.2-0.8
Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2011 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(/usr/local/bin/bashdb:272):
level 1, subshell 0, depth -1:	  . $_source_file
(/tmp/fact.sh:11):
level 1, subshell 0, depth 0:	echo fact 0 is: `fact 0`
(/tmp/fact.sh:11):
level 1, subshell 1, depth 0:	echo fact 0 is: `fact 0`
fact 0
(/tmp/fact.sh:2):
level 1, subshell 1, depth 1:	fact() {
(/tmp/fact.sh:3):
level 1, subshell 1, depth 1:	    local -i n=${1:0}
...
level 1, subshell 2, depth 2:	    echo $result
(/tmp/fact.sh:7):
level 1, subshell 1, depth 1:	    ((result=n*fact_nm1))
(/tmp/fact.sh:8):
level 1, subshell 1, depth 1:	    echo $result
fact 3 is: 6
(/usr/local/bin/bashdb:285):
level 1, subshell 0, depth -1:	

If you issue a break (e.g. send a SIGINT signal) while the program is running you will go into the debugger (assuming your program doesn’t trap SIGINT).

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.

An interrupt (often C-c) does not exit from the BASH debugger, but rather terminates the action of any the BASH debugger command that is in progress and returns to the BASH debugger command level. Inside a debugger command interpreter, use quit command (see section Quitting the BASH debugger).

There way to terminate the debugger is to use the kill command. This does more forceful kill -9. It can be used in cases where quit doesn’t work.

Running a program from the debugger adds a bit of overhead and slows down your program quite a bit. Addressing this better would mean some serious changes to BASH internals, and judging from experience in other languages there still the slowdown is still noticeable. If you have a configure script generated by autoconf, and you want to stop in the middle of the script, it can take quite a while.

Furthermore, by necessity, debuggers change the operation of the program they are debugging. And this can lead to unexpected and unwanted differences. It has happened so often that the term “Heisenbugs” (see http://en.wikipedia.org/wiki/Heisenbug) was coined to describe the situation where the addition of the use of a debugger (among other possibilities) changes behavior of the program so that the bug doesn’t manifest itself anymore.

There is another way to get into the debugger aside from calling bashdb from the outset, and this adds no overhead or slowdown until you reach the point at which you want to start debugging. However for this method you must change the script. Because the debugger isn’t involved before the first call, there is no overhead; the script will run at the same speed as if there were no debugger up to the point where it is first invoked.

After invoking the debugger you should be on the first stoppable line of your program to be debugged. At this point you can issue debugger commands to set breakpoints (see section Setting breakpoints), or watchpoints (see section Setting watchpoints), or start continue the execution of the program (see section Resuming Execution).

A command file for the BASH debugger is a file of lines that are the BASH debugger commands. Comments (lines starting with #) may also be included. An empty line in a command file does nothing; it does not mean to repeat the last command, as it would from the terminal.

When you start the BASH debugger, it automatically executes commands from its init files, normally called ‘.bashdbinit’(3). During startup, the BASH debugger does the following:

1. Reads the init file (if any) in your home directory(4).
2. Processes command line options and operands.
3. Reads the init file (if any) in the current working directory.
4. Reads command files specified by the ‘-x’ option.

The init file in your home directory can set options (such as ‘set complaints’) that affect subsequent processing of command line options and operands. Init files are not executed if you use the ‘-x’ option (see section bashdb script options).

On some configurations of the BASH debugger, the init file is known by a different name (these are typically environments where a specialized form of the BASH debugger may need to coexist with other forms, hence a different name for the specialized version’s init file). These are the environments with special init file names:

You can also request the execution of a command file with the source command:

The lines in a command file are executed sequentially. They are not printed as they are executed. If there is an error, execution proceeds to the next command in the file.

The arguments to your script can be specified by the arguments of the restart command. They are passed to a shell, which expands wild-card characters and performs redirection of I/O, and thence to your script.

restart with no arguments uses the same arguments used by the previous restart, or those set by the set args command..

By default, the script you run under the BASH debugger does input and output to the same terminal that BASH uses. Before running the script to be debugged, the debugger records the tty that was in effect. All of its output is then written to that. However you can change this when using the ‘bashdb’ script using the ‘-t’ option.

Another way to specify where your script should do input and output is with the tty command. This command accepts a file name as argument, and causes this file to be the default for future restart commands. It also resets the controlling terminal for the child process, for future restart commands. For example,

tty /dev/ttyb

directs that processes started with subsequent restart commands default to do input and output on the terminal ‘/dev/ttyb’ and have that as their controlling terminal.

An explicit redirection in restart overrides the tty command’s effect on the input/output device, but not its effect on the controlling terminal.

When you use the tty command or redirect input in the restart command, only the input for your script is affected. The input for the BASH debugger still comes from your terminal.

The BASH debugger and your program live in the same variable space so to speak. BASH does not have a notion of module scoping or lexical hiding (yet) as is found in modern programming languages and in modern versions of the Korn shell. This then imposes some additional care and awareness.

Most of the variables and functions used inside the BASH debugger start _Dbg_, so please don’t use variables or functions with these names in your program.

Note: there are some other variables that begin with just an underscore (_); over time these will be phased out. But until then, avoid those or consult what is used by the debugger. Run ‘bashdb --debugger -c "declare -p"’ to list all the variables in use including those used by the debugger.

A number of environment variables are also reserved for use; these start with DBG_. For example: DBG_INPUT, DBG_LEVEL and, _Dbg_QUIT_ON_QUIT (see section Debug), DBG_RESTART_FILE (see section Starting), to name a few. Finally, there are some BASH environment dynamic variables and these start with BASH_. For example BASH_SUBSHELL (see section Debug), BASH_COMMAND (see section Command Display), BASH_LINENO, and BASH_SOURCE to name a few.

Inside the debugger some variables may be redefined. In particular IFS and PS4, and various dollar variables $?, $1, $2, etc. The values before entering the debugger are saved and those variables have their old values restored when leaving the debugger. However you may notice these difference in various debugger commands. For example examine PS4 might not return the same value as eval declare -p PS4. The former is picking the debugger value while the eval is careful to restore the value to what it was before entering the debugger.

In order to do its work The BASH debugger sets up a DEBUG trap. Consequently a script shouldn’t reset this or the debugger will lose control. The BASH debugger also sets up an EXIT handler so that it can gain control after the script finishes. Another signal intercepted is the an interrupt or INT signal. For more information about signal handling, see section Signals

A BASH debugger command is a single line of input. There is no limit on how long it can be. It starts with a command name, which is followed by arguments whose meaning depends on the command name. For example, the command step accepts an argument which is the number of times to step, as in ‘step 5’. You can also use the step command with no arguments. Some commands do not allow any arguments.

A blank line as input to the BASH debugger (typing just <RET>) means to repeat the previous next or step command.

Any text from a # to the end of the line is a comment; it does nothing. This is useful mainly in command files (see section Command files).

Once inside the BASH debugger, you can always ask it for information on its commands, using the command help.

bashdb<0> help
Available commands:
  action     condition  edit     frame    load     run     source  unalias  
  alias      continue   enable   handle   next     search  step    undisplay
  backtrace  debug      eval     help     print    set     step-   untrace  
  break      delete     examine  history  pwd      shell   step+   up       
  clear      disable    export   info     quit     show    tbreak  watch    
  commands   display    file     kill     return   signal  trace   watche   
  complete   down       finish   list     reverse  skip    tty   

Readline command line editing (emacs/vi mode) is available.
Type "help" followed by command name for full documentation.

bashdb<0> help list
list [START|.|FN] [COUNT] -- List lines of a script.

START is the starting line or dot (.) for current line. Subsequent
list commands continue from the last line listed. If a function name
is given list the text of the function.

If COUNT is omitted, use the setting LISTSIZE. Use "set listsize" to 
change this setting.

Aliases for list: l

bashdb<0> help info
List of info subcommands:

info args -- Argument variables (e.g. $1, $2, ...) of the current stack frame.
info breakpoints -- Status of user-settable breakpoints
info display -- Show all display expressions
info files -- Source files in the program
info functions -- All function names
info line -- list current line number and and file name
info program -- Execution status of the program.
info signals -- What debugger does when program gets various signals
info source -- Information about the current source file
info stack -- Backtrace of the stack
info terminal -- Print terminal device
info variables -- All global and static variable names
info warranty -- Various kinds of warranty you do not have

Aliases for info: i
bashdb<1> info source
Current script file is parm.sh
Located in /tmp/parm.sh
Contains 34 lines.

One important use of a debugger is to stop your program before it terminates so that if your script might run into trouble, you can investigate and find out why. However should your script accidentally continue to termination, the BASH debugger has arranged for it not to leave the debugger without your explicit instruction. That way, you can restart the program using the same command arguments.

Inside the BASH debugger, your script may stop for any of several reasons, such as a signal, a breakpoint, or reaching a new line after a debugger command such as step. You may then examine and change variables, set new breakpoints or remove old ones, and then continue execution.

When your script has stopped, one thing you’ll probably want to know is where it stopped and some idea of how it got there.

Each time your script performs a function call (either as part of a command substitution or not), or ‘source’s a file, information about this action is saved. The call stack then is this a history of the calls that got you to the point that you are currently stopped at.

One of the stack frames is selected by the BASH debugger and many the BASH debugger commands refer implicitly to the selected frame. In particular, whenever you ask the BASH debugger to list lines without giving a line number or location the value is found in the selected frame. There are special the BASH debugger commands to select whichever frame you are interested in. See section Selecting a frame.

When your program stops, BASH automatically selects the currently executing frame and describes it briefly, similar to the frame command.

the BASH debugger can print parts of your script’s source. When your script stops, the BASH debugger spontaneously prints the line where it stopped. Likewise, when you select a stack frame (see section Selecting a frame), the BASH debugger prints the line where execution in that frame has stopped. You can print other portions of source files by explicit command.

If you use the BASH debugger through its GNU Emacs interface, you may prefer to use Emacs facilities to view source.

To print lines from a source file, use the list command (abbreviated l). By default, ten lines are printed. There are several ways to specify what part of the file you want to print.

Here are the forms of the list command most commonly used:

By default, the BASH debugger prints ten source lines with any of these forms of the list command. You can change this using set listsize:

Repeating a list command with <RET> discards the argument, so it is equivalent to typing just list. This is more useful than listing the same lines again. An exception is made for an argument of ‘-’; that argument is preserved in repetition so that each repetition moves up in the source file.

In general, the list command expects you to supply a linespecs. Linespecs specify source lines; there are several ways of writing them, but the effect is always to specify some source line.

Here is a complete description of the possible arguments for list:

Here are the ways of specifying a single source line—all the kinds of linespec.

To edit the lines in a source file, use the edit command. The editing program of your choice is invoked with the current line set to the active line in the program. Alternatively, you can give a line specification to specify what part of the file you want to print if you want to see other parts of the program.

You can customize to use any editor you want by using the EDITOR environment variable. The only restriction is that your editor (say ex), recognizes the following command-line syntax:

ex +number file

The optional numeric value +number specifies the number of the line in the file where to start editing. For example, to configure the BASH debugger to use the vi editor, you could use these commands with the sh shell:

EDITOR=/usr/bin/vi
export EDITOR
gdb …

or in the csh shell,

setenv EDITOR /usr/bin/vi
gdb …

There are two commands for searching through the current source file for a BASH extended pattern-matching expression.

One way to examine string data in your script is with the print command (abbreviated p). However a more versatile print command is x; it can print variable and function definitions and can do arithmetic computations. Finally, the most general method would be via eval echo.

bashdb<0> print the value of x is $x
the value of x is 22
bashdb<1> p The home directory for root is ~root
The home directory for root is /root
bashdb<2> p '*** You may have won $$$ ***'
*** You may have won $$$ ***
bashdb<3> # Note the use of the single quotes.
bashdb<3> # Compare what happens with double quotes or no quotes

bashdb<0> examine x y
declare -- x="22"

declare -- y="23"
bashdb<1> examine x+y
45
bashdb<2> x fn1
fn1 () 
{ 
    echo "fn1 here";
    x=5;
    fn3
}
bashdb<2> x FUNCNAME

declare -a FUNCNAME='([0]="_Dbg_cmd_x" [1]="_Dbg_cmdloop" [2]="_Dbg_debug_trap_handler" [3]="main")'

bashdb<0> V dq*
dq_args="dq_*"
dq_cmd="V"
bashdb<1> V FUNCNAME

FUNCNAME='([0]="_Dbg_cmd_list_variables" [1]="_Dbg_cmdloop" [2]="_Dbg_debug_trap_handler" [3]="main")'

If you find that you want to print the value of an expression frequently (to see how it changes), you might want to add it to the automatic display list so that the BASH debugger evaluates a statement each time your program stops. Each expression added to the list is given a number to identify it; to remove an expression from the list, you specify that number. The automatic display looks like this:

2 (echo $x): 38

This display shows item numbers, expressions and their current values.

The two most general commands and most “low-level” are eval and shell.

(/etc/apparmor/functions:24):
PROFILES="/etc/apparmor.d"
bashdb<2> 

(/etc/apparmor/functions:24):
PROFILES="/etc/apparmor.d"
bashdb<2> eval
eval: PROFILES="/etc/apparmor.d"

$? is 0
bashdb<3> 

(/etc/init.d/apparmor:70):
if [ "$1" = "recache" ]

bashdb<2> pr $1
status

bashdb<1> eval?
eval: [ "$1" = "recache" ]
$? is 1

bashdb /etc/init.d/apparmor status
bashdb debugger, release 4.2-0.8

Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010, 2011 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
...
(/etc/init.d/apparmor:35):
. /etc/apparmor/functions
bashdb<1> s
(/etc/apparmor/functions:24):
PROFILES="/etc/apparmor.d"

bashdb<2> s
(/etc/apparmor/functions:25):
PARSER="/sbin/apparmor_parser"
bashdb<3> shell
bashdb $ typeset -p PROFILES
typeset -p PROFILES
typeset PROFILES=/etc/apparmor.d
bashdb $ PROFILES='Hi, Mom!'
bashdb $ save_vars PROFILES
bashdb $  <EOF>
(/etc/apparmor/functions:25):
PARSER="/sbin/apparmor_parser"
bashdb<4> x PROFILES
typeset PROFILES='Hi, Mom!'

In addition to help, you can use the BASH commands info and show to inquire about the state of your program, or the state of BASH itself. Each command supports many topics of inquiry; here we introduce each of them in the appropriate context. The listings under info and under show in the Index point to all the sub-commands. See section Command Index.

You can alter the way BASH interacts with you in various ways given below.

If you are not sure whether you have found a bug, here are some guidelines:

• If the debugger gets a fatal signal, for any input whatever, that is a the BASH debugger bug. Reliable debuggers never crash.
• If the BASH debugger produces an error message for valid input, that is a bug. (Note that if you’re cross debugging, the problem may also be somewhere in the connection to the target.)
• If the BASH debugger does not produce an error message for invalid input, that is a bug. However, you should note that your idea of “invalid input” might be our idea of “an extension” or “support for traditional practice”.
• If you are an experienced user of debugging tools, your suggestions for improvement of the BASH debugger are welcome in any case.

Bug reports can sent via the sourceforge bug tracking mechanism at http://sourceforge.net/tracker/?group_id=61395&atid=497159. Of course patches are very much welcome too. Those can also be sent via the same mechanism.

The fundamental principle of reporting bugs usefully is this: report all the facts. If you are not sure whether to state a fact or leave it out, state it!

Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of the variable you use in an example does not matter. Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the debugger into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful.

Keep in mind that the purpose of a bug report is to enable us to fix the bug. It may be that the bug has been reported previously, but neither you nor we can know that unless your bug report is complete and self-contained.

Sometimes people give a few sketchy facts and ask, “Does this ring a bell?” Those bug reports are useless, and we urge everyone to refuse to respond to them except to chide the sender to report bugs properly.

To enable us to fix the bug, you should include all these things:

• The version of the BASH debugger. the BASH debugger announces it if you start with no arguments; you can also print it at any time using version command.

  Without this, we will not know whether there is any point in looking for the bug in the current version of the BASH debugger.

• The type of machine you are using, and the operating system name and version number.
• What compiler (and its version) was used to compile BASH—e.g. “gcc 3.4”.
• The command arguments you gave the compiler to compile your example and observe the bug. For example, did you use ‘-O’? To guarantee you will not omit something important, list them all. A copy of the Makefile (or the output from make) is sufficient.

  If we were to try to guess the arguments, we would probably guess wrong and then we might not encounter the bug.

• A complete input script, and all necessary source files, that will reproduce the bug.
• A description of what behavior you observe that you believe is incorrect. For example, “It gets a fatal signal.”

  Of course, if the bug is that the BASH debugger gets a fatal signal, then we will certainly notice it. But if the bug is incorrect output, we might not notice unless it is glaringly wrong. You might as well not give us a chance to make a mistake.

  Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of the BASH debugger is out of synch, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and ours would not. If you told us to expect a crash, then when ours fails to crash, we would know that the bug was not happening for us. If you had not told us to expect a crash, then we would not be able to draw any conclusion from our observations.

• If you wish to suggest changes to the the BASH debugger source, send us context diffs. If you even discuss something in the the BASH debugger source, refer to it by context, not by line number.

  The line numbers in our development sources will not match those in your sources. Your line numbers would convey no useful information to us.

Here are some things that are not necessary:

• A description of the envelope of the bug.

  Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it.

  This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. We recommend that you save your time for something else.

  Of course, if you can find a simpler example to report instead of the original one, that is a convenience for us. Errors in the output will be easier to spot, running under the debugger will take less time, and so on.

  However, simplification is not vital; if you do not want to do this, report the bug anyway and send us the entire test case you used.

• A patch for the bug.

  A patch for the bug does help us if it is a good one. But do not omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all.

  Sometimes with a program as complicated as the BASH debugger it is very hard to construct an example that will make the program follow a certain path through the code. If you do not send us the example, we will not be able to construct one, so we will not be able to verify that the bug is fixed.

  And if we cannot understand what bug you are trying to fix, or why your patch should be an improvement, we will not install it. A test case will help us to understand.

• A guess about what the bug is or what it depends on.

  Such guesses are usually wrong. Even we cannot guess right about such things without first using the debugger to find the facts.

The GNU General Public License is a free, copyleft license for software and other kinds of works.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

The precise terms and conditions for copying, distribution and modification follow.

The purpose of this License is to make a manual, textbook, or other written document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you.”

A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not “Transparent” is called “Opaque.”

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text. 

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies. 

If you publish printed copies of the Document numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled “History”, and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
K. In any section entitled “Acknowledgements” or “Dedications”, preserve the section’s title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section entitled “Endorsements.” Such a section may not be included in the Modified Version.
N. Do not retitle any existing section as “Endorsements” or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled “History” in the various original documents, forming one section entitled “History”; likewise combine any sections entitled “Acknowledgements”, and any sections entitled “Dedications.” You must delete all sections entitled “Endorsements.” 

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an “aggregate”, and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document’s Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. 

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. 

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (C)  year  your name.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the Invariant Sections being list their titles, with the
Front-Cover Texts being list, and with the Back-Cover Texts being list.
A copy of the license is included in the section entitled "GNU
Free Documentation License."

If you have no Invariant Sections, write “with no Invariant Sections” instead of saying which ones are invariant. If you have no Front-Cover Texts, write “no Front-Cover Texts” instead of “Front-Cover Texts being list”; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

• Show/hide all -- click the top right-hand asterisk.
• Find text -- show all, then use browser's find
• Geek modes --
• ctrl-shift asterisk extracts <pre>-formatted text into a text box (for synchronizing documentation with code).
  
• ctrl asterisk prompts for jquery/javascript command
• shift asterisk places HTML body without grey decoration boxes, into a text box, for post-disaster (partial) recovery of an otherwise lost outline.
  

Outline editor -- which constructs the outline

• Stores outline source as a javascript object notation (JSON) 'huge' text record.
• Three storage modes are available --
• Storage via clipboard to a text editor
• Storage in your own browser's localStore
• Storage in a server's mysql database
• Menu-driven options available - more user-friendly
• Primary creation mode for html web page is Firefox browser preview, then save-as web page.
  
• New tools help conversion from html, pdf etc
  
• Moved from jslinb's site to rodericksmith.dyndns.org (server link to my office).  Guest login is available.
  
• Multi-user precaution -- prompts if the record's timestamp has changed since loading
• User-specific permissions for databases and tables storing outlines
  

Bashdb specific

• Navigation duplication removed
• Links in headings fixed in the footnotes
  
• Update to 4.2-0.6 Edition, 7 December 2010