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.0-0.3
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: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 by the Perl debugger and is also in the same format used by my GNU make debugger ( http://bashdb.sourceforge.net/remake ) the Extended Python Debugger http://remake.sourceforge.net/pydb , and one for Ruby ( http://bashdb.sorceforge.net/ruby-debug.html ). GNU Emacs and DDD can parse this and in fact the same regular expression is used on the 3 debuggers.

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 bashdb 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, aslo 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.0-0.3
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.0-0.3
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.

(/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. By default, both debugging in Emacs via GUD ( Using the BASH debugger under Emacs ) and debugging via DDD work via this method.

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.

* Debugging a Running Shell Script 2.3.2 Program-Controlled Line Tracing  

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 wildcard 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 langauges 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 restroed 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:
  /          debug    enable   help     next     show    step-      untrace
  alias      delete   eval     history  print    signal  tbreak     up     
  break      disable  examine  info     pwd      skip    trace      watch  
  commands   display  file     kill     quit     source  tty        where  
  condition  down     frame    list     restart  step    unalias  
  continue   edit     handle   load     set      step+   undisplay

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

bashdb<0> help list
l linespec      List window lines starting at linespec.
l min incr      List incr lines starting at 'min' linespec.
l               List next window of lines.
l .             Same as above.
                Long command name: list.

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
bashdb<1> info source
Current script file is 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 accidently 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.

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 .

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; see Using the BASH debugger under GNU Emacs .

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")'

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

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.

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

A special interface allows you to use GNU Emacs to view (and edit) the source files for the program you are debugging with the BASH debugger. However you must be using GNU Emacs version 21 or greater. ( M-x show-emacs-version inside GNU Emacs will tell you what version you are running.)

To use this interface, use the command M-x bashdb in GNU Emacs. Give the executable file you want to debug as an argument. Make sure to use the version that comes with this package as this is newer than that supplied with GNU Emacs.

The bashdb command starts the BASH debugger as a subprocess of Emacs, with input and output through a newly created Emacs buffer.

Using the BASH debugger under Emacs is just like using the BASH debugger normally except for two things:

• All “terminal” input and output goes through the GNU Emacs buffer.

This applies both to the BASH debugger commands and their output, and to the input and output done by the program you are debugging.

This is useful because it means that you can copy the text of previous commands and input them again; you can even use parts of the output in this way.

All the facilities of GNU Emacs' Shell mode are available for interacting with your script. In particular, you can send signals the usual way—for example, C-c C-c for an interrupt, C-c C-z for a stop.

the BASH debugger support is rather new in DDD . As a programming language, the BASH debugger is not feature rich: there are no record structures or hash tables (yet), no pointers, package variable scoping or methods. So much of the data display and visualization features of DDD are disabled.

As with any scripting or interpreted language (e.g. Perl), one can't step by a single machine-language instruction. So the ddd Stepi/Nexti commands are disabled.

Some BASH settings are essential for DDD to work correctly. These settings with their correct values are:

set annotate 1
set prompt set prompt bashdb$_Dbg_less$_Dbg_greater$_Dbg_space

DDD sets these values automatically when invoking BASH ; if these values are changed, there may be some malfunctions.

Pay special attention when the prompt has extra angle brackets (a nested shell) or has any parenthesis (is in a subshell). Quitting may merely exit out of one of these nested (sub)shells rather than leave the program.

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 mechansim 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 licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) 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 this service 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 make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. 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.

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

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

TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The “Program”, below, refers to any such program or work, and a “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term “modification”.) Each licensee is addressed as “you”.

   Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

2. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

   You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

3. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
   1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
   2. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
   3. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

   These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

   Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

   In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

4. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
   1. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
   2. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
   3. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

   The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

   If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

5. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program 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.
6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
7. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
8. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

   If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

   It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

   This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

9. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
10. The Free Software Foundation may publish revised and/or new versions of the General Public 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.

    Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

11. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

    NO WARRANTY

12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

one line to give the program's name and a brief idea of what it does.
Copyright (C) year  name of author

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.

The hypothetical commands ‘ show w ’ and ‘ show c ’ should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than ‘ show w ’ and ‘ show c ’; they could even be mouse-clicks or menu items—whatever suits your program.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.

signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

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.