Page 1 of 1
Finding programming errors is hard
Posted: Sun 11 Apr 2010, 17:23
by 8-bit
When writing a program in bash or gtkdialog3, the programmer sometimes has a bad time with errors as all errors are not shown when running the program from a terminal.
An error is shown. It might be a configuration file input error where the values you think are being passed are not.
It might be something else.
But fix one error and another that was not reported shows up.
I think some users really do not appreciate the effort that goes into writing a program, or for that matter, an OS that just works.
It is not as simple as it seems.
Rant ended.
Re: Programming errors
Posted: Sun 11 Apr 2010, 18:16
by DMcCunney
8-bit wrote:When writing a program in bash or gtkdialog3, the programmer sometimes has a bad time with errors as all errors are not shown when running the program from a terminal.
Bash programmers may wish to look at this:
http://bashdb.sourceforge.net/
______
Dennis
Re: Programming errors
Posted: Sun 11 Apr 2010, 21:06
by 8-bit
DMcCunney wrote:8-bit wrote:When writing a program in bash or gtkdialog3, the programmer sometimes has a bad time with errors as all errors are not shown when running the program from a terminal.
Bash programmers may wish to look at this:
http://bashdb.sourceforge.net/
______
Dennis
Maybe I downloaded the wrong file, but when I tried to compile it, it said bash in puppy was not a new enough version.
So I will see if an older version is offered.
Re: Programming errors
Posted: Sun 11 Apr 2010, 21:25
by big_bass
8-bit wrote:DMcCunney wrote:8-bit wrote:When writing a program in bash or gtkdialog3, the programmer sometimes has a bad time with errors as all errors are not shown when running the program from a terminal.
Bash programmers may wish to look at this:
http://bashdb.sourceforge.net/
______
Dennis
Maybe I downloaded the wrong file, but when I tried to compile it, it said bash in puppy was not a new enough version.
So I will see if an older version is offered.
I compiled it awhile ago I think back on puppy 3.01
I havent used it since then
I just write in small sections at a time and echo out stuff to verify things
and with every edit make a new file so you can always go back to where it worked
I just wrote a package management tool I studied how it worked for months... before writing one line of code
yes it is work but you gotta love it
make a dragN drop script for testing
Code: Select all
#!/bin/bash
xterm -geometry 100x10+10+20 -e sh -x "$@"
also you could also do this overkill but sometimes you need it
Code: Select all
rxvt -geometry 90x30+650+40 -e /usr/bin/strace /usr/share/doc/gtkdialog3/examples/01.00-button
where
/usr/share/doc/gtkdialog3/examples/01.00-button
could be a bash script gtkdialog or whatever executble
Joe
Posted: Sun 11 Apr 2010, 21:28
by sunburnt
It works... Now it doesn`t work... Oooooooo, where have I experienced that before?
Posted: Mon 12 Apr 2010, 18:22
by Pizzasgood
You can use the set -x command to enable debug mode (and set +x to disable it). Alternately, to enable it for the entire script, add the -x to the shebang, ala #!/bin/sh -x
That way the program will automatically echo some information about each command before it is executed, and expands all variables. That can help with figuring out what's going on.
Posted: Mon 12 Apr 2010, 18:28
by 8-bit
Thank you Pizzasgood!
Now that is a very useful piece of information.
One problem though.
Most of the time, that info is displayed and disappears before you can grasp it.
I will try it though.
Posted: Mon 12 Apr 2010, 19:00
by RetroTechGuy
8-bit wrote:Thank you Pizzasgood!
Now that is a very useful piece of information.
One problem though.
Most of the time, that info is displayed and disappears before you can grasp it.
I will try it though.
You're working on the command line? Can you not scroll backwards with the mouse roller? (there is no scroll bar on the side, but it will roll back with the scroll function -- under 4.3.1, anyway).
I often expand the rxvt window to full screen, so it limits the number of wrapped lines.
You could alternatively redirect the errors to a log file of some sort.
Posted: Mon 12 Apr 2010, 19:36
by Sit Heel Speak
#!/bin/sh -e
makes the script halt on error and return to the command prompt.
Perhaps you could combine the two, i.e.
#!/bin/sh -e -x
Posted: Mon 12 Apr 2010, 19:47
by sunburnt
I`ve use Bash debugging, but so often you need to know the output or value of something.
Nothing replaces the good old "echo" command for really knowing what`s going on...
In Visual Basic you can "swipe highlight" a variable, equation, or an entire line to get it`s value.
And of course Basic`s : break, line watch, and stepping control. A "posh" environment...
Posted: Tue 13 Apr 2010, 00:04
by DMcCunney
8-bit wrote:Thank you Pizzasgood!
Now that is a very useful piece of information.
One problem though.
Most of the time, that info is displayed and disappears before you can grasp it.
I will try it though.
If bash write error messages to standard error, "sh -x script 2> error.log" should capture the error messages.
Alternatively, "sh -x script | tee script.log" should capture the output in script.log as well as showing it on screen.
______
Dennis
Posted: Tue 13 Apr 2010, 00:25
by technosaurus
if you want a gui if there are errors you can check if "`cat error.log`" != "" and then display it with Xdialog --infobox ...or something similar (xmessage, yafsplash...) the only problem is some commands that use stderr instead of stdout (ffmpeg comes to mind if I recall correctly)
Posted: Tue 13 Apr 2010, 23:33
by Pizzasgood
You can scroll (even on the raw commandline w/o X) by pressing Shift and the Page Up or Page Down buttons. Useful sometimes.
combining error output, "state"
Posted: Wed 14 Apr 2010, 13:00
by prehistoric
technosaurus wrote:...the only problem is some commands that use stderr instead of stdout (ffmpeg comes to mind if I recall correctly)
If you want the error and standard output to be combined for debugging, you can, of course, append this to the command.
Although I am no longer actively programming, aging has taught me, by reducing my working memory, that errors in state-based reasoning are behind many bugs like those discussed here. If you are dealing with simple machines with a single program counter directly executing straight-forward machine code, the idea of state seems pretty simple. The x86 series is no longer so simple, even without complicated systems software.
By the time you get to distributed systems where different parts of the state are at different places, and accessed at different times, the concept of state is no longer simple. I have witnessed a room full of PhDs arguing about what one object in a distributed system "knew" about the state of another object. It sounded a lot like arguments about what is "really going on" in quantum mechanics and relativity.
Beware of code that places great demands on this kind of memory and understanding.
Re: combining error output, "state"
Posted: Wed 14 Apr 2010, 21:18
by RetroTechGuy
prehistoric wrote:technosaurus wrote:...the only problem is some commands that use stderr instead of stdout (ffmpeg comes to mind if I recall correctly)
If you want the error and standard output to be combined for debugging, you can, of course, append this to the command.
Although I am no longer actively programming, aging has taught me, by reducing my working memory, that errors in state-based reasoning are behind many bugs like those discussed here. If you are dealing with simple machines with a single program counter directly executing straight-forward machine code, the idea of state seems pretty simple. The x86 series is no longer so simple, even without complicated systems software.
By the time you get to distributed systems where different parts of the state are at different places, and accessed at different times, the concept of state is no longer simple. I have witnessed a room full of PhDs arguing about what one object in a distributed system "knew" about the state of another object. It sounded a lot like arguments about what is "really going on" in quantum mechanics and relativity.
Beware of code that places great demands on this kind of memory and understanding.
Thanks Prehistoric. That jogged my memory... Which helped me find these:
http://www.linuxsa.org.au/tips/io-redirection.html
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html