SHORT INSTRUCTIONS: 0. download the latest bash debugger from: http://prdownloads.sourceforge.net/bashdb/?sort_by=date&sort=desc The name should start out bashdb-3.x... and ungzip/untar it. If you are reading this, you've probably done that already. 1. Make your current directory the debugger directory. If you want the bash extension command readarray that speeds up loading of large scripts than read step 3 of the long instructions especially down at the bottom. Basically to speed up the initialy debugger loading, you need the bash source headers and need to run configure using --with-bash-src. configure, build, test, and install the debugger: cd bashdb-3.x... # <-- put name of release for 3.x... ./configure # use --with-bash-src to speed up bash debugging make && make check su -c 'make install' On systems which don't install GNU Make by default you may have to use "gmake" instead of "make". In creating files and directories for the bashdb, beware that the umask of the account performing the installation is consulted as it would be for any new file or directory. In particular, if your umask is, for example, 007, then directories that get created will have permission drwx------ which only allows that user to access the debugger support files. Since the root account sometimes has that umask, you may want to set the umask to something more permissive like 022, before running the "make install". That's it! - - - - This debugger needs a debugger-enabled version of Bash 3.2 or greater. It is possible to try out the debugger without installing it by using the bashdb script that is in this directory. To do so you would invoke your script as follows, assuming you are currently in the directory (debugger) that you originally found this file in. $BASH -L . ./bashdb *script-to-be-debugged* *options-to-debugged-program* where $BASH above is bash 3.0 with debugging enabled. A downside to this approach is that $0 in will be ``bashdb'' (or more likely ``./bashdb'') rather than the name of the script to be debugged. Also, the parameters to the bashdb invocation do not appear in a stack trace. If this is a problem, then you will have to install the debugger, or modify the script to be debugged to point to the debugger-enabled version of bash. For example if your script were in this directory (debugger) as well is your current working directory (as shown by ``pwd''), then having this at the beginning of your script: #!/some-location/bash --debugger might also work. For information on the differences between "bash --debugger" and bashdb, see Chapter 2 (Getting In and Out) of the bashdb documentation (bashdb.info, bashdb.html, or bashdb.texi) Steps 0 and 1 you've probably already done if you are reading these instructions. 0. download the latest bash debugger from: http://prdownloads.sourceforge.net/bashdb/?sort_by=date&sort=desc The name should start out bashdb-3.x... 1. ungzip/untar the bashdb debugger package. gzcat bashdb-3.x... | tar -xvpf - # <-- put name of release for 3.x... (There's a shorter way to do this GNU tar 1.15 or later) 2. Make your current directory the debugger directory. cd bashdb-3.x... 3. Look at configure help options and decide what you want: ./configure --help is your friend here. On those OS's that support it, you will probably want the extension which enables reading large arrays fast and makes loading of large scripts (e.g. configure) much quicker. For this you need the bash source or at least the headers since we need to compile against that. And you need to tell configure where to use it via --with-bash-src. It is important that the source match the bash that is going to be used when debugger. For example using bash release 3.1 source for an installed bash 3.0 binary will not work as there are incompatiblities. Should you have several bash binaries around, you can tell configure which one you want to use for the debugger via the option --with-bash. For --with-bash use absolute paths, not relative paths or the regression tests will fail. 4. configure the debugger to suit your needs: ./configure # you may want to add options gleened from step 3 above. # in particular --with-bash-src. There is a lot of verbiage, but do pay attention to any errors or warning you see here. 5. Build: make # make options, but I think none are generally needed Any old "make" should work, but if it doesn't, use GNU make (sometimes installed as "gmake". Again, even though there is verbiage pay attention to errors. If you don't have texi2html you may see some errors in building HTML pages; these you can ignore. 6. Run the regression tests: make check # or gmake check 7. Install the debugger: su -c 'make install' As above, pay attention to errors. In particular here if you don't have permission to fully install or overwrite existing files you may get a message that you can't run "bash --debugger" but must use the "bashdb" script. See above for a larger discussion of the difference. No, really. that's it!