Bashdb

• Introduction
• Installation
• Invocation
• Getting help
• Dynamic activation from scripts
• SUPPLEMENT: installation instruction in file INSTALL that comes with the tarball

Introduction

Bashdb is nice debugger for bash, but usually it is not installed by default. You either need to install it from source using version 3 if you have bash 3 and version 4 if you have bash 4.1 or bash 4.2. 

RHEL 7 uses bash 4.2, so for it you can use bashdb-4.4-1.0.1.tar.gz from bash debugger download - SourceForge.net

The versions are stored at the tree at https://sourceforge.net/projects/bashdb/files/bashdb/

See BASH with Debugger and Improved Debug Support and Error Handling or to the link to the tarball.

Command are similar to Perl debugger so users of Perl can instantly feel at home using it. 

Documentation is available at

• manual page
• tree-structured reference manual

 Installation

 Installation consist of just three commands

1. Make your current directory the debugger directory.

2. run commands

cd bashdb*           # <-- put name of release for Bash 4.2 or other version that you have..
./configure          # use --with-bash-src to speed up bash debugging
make && make check 
su -c 'make install' # should run as root

If those steps run OK, you should have debugger available in /usr/local/bin   and you can call it using the command

bashdb --help

[root@icontainer home]# bashdb --help
Usage:
   bashdb [OPTIONS] <script_file>

Runs bash <script_file> under a debugger.

options:
    -h | --help             Print this help.
    -q | --quiet            Do not print introductory and quiet messages.
    -A | --annotate  LEVEL  Set the annotation level.
    -B | --basename         Show basename only on source file listings.
                            (Needed in regression tests)
    --highlight | --no-highlight
                            Use or don't use ANSI terminal sequences for syntax
                            highlight
    --init-file FILE        Source script file FILE. Similar to bash's
                            corresponding option. This option can be given
                            several times with different files.
    -L | --library DIRECTORY
                            Set the directory location of library helper file: /usr/local/share/bashdb/dbg-main.sh
    -c | --command STRING   Run STRING instead of a script file
    -n | --nx | --no-init   Don't run initialization files.
    --tty | --terminal DEV  Set to terminal in debugger output
    -T | --tempdir DIRECTORY
                            Use DIRECTORY to store temporary files
    -V | --version          Print the debugger version number.
    -X | --trace            Set line tracing similar to set -x
    -x | --eval-command CMDFILE
                            Execute debugger commands from CMDFILE.

Invocation

You can use debugger even without installation. In this case you need to be in the directory you untared it and use the option “-L .”:

bash -L ./bashdb script-to-be-debugged options-to-debugged-program

If bashdb has been installed you don’t need to use option “-L .” Instead you would type simply

bashdb script-to-be-debugged options-to-debugged-program

I would recommend to check syntax of the bash script before using the debugger using option "-n", for example 

bash -n your_script.sh

Let's summarize the essentials of the debugger invocation:

1. type bash --debugger script-name  or bashdb script-name to start the BASH debugger. 
2. type bashdb -c command string to run a command or one-liner under the debugger.
3. Or type bashdb -h  to get help about options available (bashdb --help   works too)

Two useful commands are n (next) - next step and p (print) -- print the variable or expression. Type quit or C-d inside the debugger to exit. Other way to terminate the debugger is to use the kill command. kill -9 can be used in cases where quit doesn't work.

Getting 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

Basdb documentation has several examples on how to use bashdb. See  Summary of the BASH Debugger

Dynamic activation from scripts

You can activate the debugger within the script. you can make an explicit call to the debugger in your script

_Dbg_debugger 

Here is an example:

  for ((i=1; i<=10; i++)) ; 
        (( 5 == i )) && { _Dbg_debugger }
        date=$(date)
        echo "$date"
        sleep 2
  done 

You can also turn on and off line tracing with _Dbg_linetrace_on

Frontends

There are also two front-ends available as well. One can also enter the debugger inside emacs via the command M-x bashdb after loading Emacs' Grand Unified Debugger, gud. See Using the BASH debugger from GNU Emacs.

And there is support in a DDD for bash.

Getting the bashdb

bashdb is available as a source package in Debian, Fedora and OpenSuse. The Ubuntu repository contains a package for bashdb too.

Please note that for bash 4.x you need   version of bashdb, version 4.x, while for bash 3.x. version of bashdb should be 3.0.x.

Tarball with debugger is downloadable from Sourceforge:

https://sourceforge.net/project/showfiles.php?group_id=61395

SUPPLEMENT: installation instruction in file INSTALL that comes with the tarball

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!

LONG INSTRUCTIONS

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!

Recommended Links

Softpanorama Recommended

Top articles

Sites

• BASH with Debugger and Improved Debug Support and Error Handling
• BASH Debugger  -- Getting started
• BASH Debugger Debugging with the BASH debugger
• rpmseek.com - The search engine for Linux rpm and Debian packages
• bashdb-4.0_0.4-1.pm.2.1.x86_64.rpm - openSUSE 11.3 - Download & Review
• bashdb-4.0_0.4-2.fc13.noarch RPM

Reference

• Options
  • -h | --help
  • This option causes the BASH debugger to print some basic help and exit.
  • -V | --version
  • This option causes the BASH debugger to print its version number, no-warranty blurb, and exit.
  • -A | --annotate level
  • Add additional output which allows front-ends to track what's going on without having to poll for such vital information. The default annotation level is 0 (none). If you are running inside GNU Emacs using the Emacs code from this package, an annotation level 3 when set will allow for automatic tracking of frames and breakpoints. See section Annotation Level (‘set annotate’).
  • -c | --command cmd
  • Run the string instead of running a script
  • -B | --basename
  • This option causes the BASH debugger to print its version number and no-warranty blurb, and exit.
  • -n | --nx | --no-init
  • Do not execute commands found in any initialization files. Normally, BASH executes the commands in these files after all the command options and arguments have been processed. See section Command files.
  • -q | --quiet
  • “Quiet”. Do not print the introductory and copyright messages. These messages are also suppressed in batch mode.
  • -t | --terminal | --tty tty
  • “Terminal output”. Set the file or terminal that you want debugger command output to go to. Note that the debugger output is independent of the debugged script output.
  • -x | --eval-command
  • execute debugger commands from cmdfile.
  • -L | --library directory
  • Set directory where debugger files reside to directory. The default location is ../lib/bashdb relative to the place that the bashdb script is located. For example if bashdb is located in /usr/local/bin/bashdb, the default library location will be /usr/local/lib/bashdb which may or may not exist. If it doesn't you'll get an error when you run bashdb. Only if the default location is incorrect, should you need to use the -L option.
  • -T | --tempdir directory
  • Set directory to use for writing temporary files.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: August 22, 2020