Debugging bash scripts.

[Mike Marchywka]

>____________________________________
>From: ubuntu-users <ubuntu-users-bounces at lists.ubuntu.com> on behalf of Ian Bruntlett <ian.bruntlett at gmail.com>
>Sent: Saturday, February 16, 2019 2:11 PM
>To: Ubuntu user technical support, not for general discussions
>Subject: Re: Debugging bash scripts.
>
>Hi Ralf,
>
>Thanks for your replies. I'm looking for a Bash debugger because I'm working my way through "The Linux Command Line" (downloadable as a PDF from http://linuxcommand.org/tlcl.php  - I have the printed version) and I am being thorough and want to use Bash and a debugger to gain fluency in bash.

As an interpretter it is a bit different from debugging compiled languages.
You also have the added flexibility in that optimization and speed are almost never
a factor- otherwise you would compile and the code is almost always concise. 

I just installed 'Beaver on a USB stick and cleaned up a lot of "junk directories" where I did not
bother to separate documents or projects. In the process I ended up with some scripts
that I named things like "setup" that reside in each project directory and may invoke a chain
higher up- ../setup calls ../setup etc and some global setup that just needs to be on the path and
defines global variable like places for scripts to put data. Also use scripts as documentation
for things like latex search path variables. 
I also ahve scripts that go get data from unstructured web pages- trying to take a link to
an article and get the bibtex for that article so I can reference it in my own work. This can 
involve scraping the link but often just comes down to getting a doi and calling crossref.
Between the page scaping and network there is a lot that can go wrong  and can be
hard to debug. .

In that process I just found that syntax errors come up much later as it is hard
to get good coverage like a compiler may get. But also if you read things like config scripts
you can see that just about anything can vary locally and you can get some usages ideas from things like
that. But anyway my point was for debugging I just finally made methods for everything-
so for example none of the scripts   will call "wget" but rather have variables with values like 
"/foo/wget -q" or "/foo/wget -S -v" depending on how debug flags are set. 
This let's you easily debug for learning and dealing with unexpected web events.

The great thing is that when you are done you have tractable documentation 
on what you have done and what needs to be done. This differs from point and click 
on things. 

fwiw

>
>BW,
>
>
>Ian
>
>--
>-- ACCU - Professionalism in programming - http://www.accu.org
>-- My writing - https://sites.google.com/site/ianbruntlett/
>-- Free Software page - https://sites.google.com/site/ianbruntlett/home/free-software
>



note new address
 Mike Marchywka 306 Charles Cox Drive Canton, GA 30115
 2295 Collinworth  Drive Marietta GA 30062.  formerly 487 Salem Woods Drive Marietta GA 30067 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency


____