Graphical debugger for bash - debugging

Is it there any graphical debugger for bash on mac os x or linux? I mean something in the same fashion that the debugging mode of Visual Studio or Eclipse, where one can stop the program hover the mouse pointer over variables and get instantly values, modify them and go backwards and try modifications without the need to start the program fomr the beginning. I am talking about very long bash scripts

for debugging execute your script with:
bash -x <scriptname>
gui debugger:
http://bashdb.sourceforge.net/

Debugger for Bash version 3(Bourne again shell). Plugin for Eclipse. Will only work with shell script editor ShellEd.
http://sourceforge.net/projects/basheclipse/

I have found the vscode-bash-debug
extension (https://github.com/rogalmic/vscode-bash-debug) for the visual studio code editor (https://code.visualstudio.com/) very useful.

I haven't come across a visual debugger, but bashdb works quite well for debugging. You can set breakpoints, continue, print variables etc..
https://sourceforge.net/projects/bashdb/
Install via your distro's repositories. There is a quick-start guide here:
http://www.rodericksmith.plus.com/outlines/manuals/bashdbOutline.html
(first chapter takes only half an hour to read/try).

Related

Getting frame variables from Python Runtime - pycharm

After updating to PyCharm 2019. my programs run incredibly slowly and with every command in the python console I can see a background task running "getting frame variables from python runtime".
This was not happening in the older version of the IDE and it has made my programs incredibly slow. Any pointers on whats happening and how I can resolve this?
Make sure uncheck the box indicated:

How do I open a program in a Win32 Console without cmd.exe?

I have little previous experience with Windows (for programming, anyway), but recognizing that Windows has an enormous market share, I am trying to support it in my programs (even though they are just for fun, I like to pretend they're big projects). I have written a tiny shell with minimal (and when I say minimal, I mean minimal) features.
I am trying to port it to Windows and would like to use it independently from cmd.exe in a Win32 Console window (meaning the shell part of cmd.exe isn't running at all, but the window used for it shows). I have already done most of the other porting stuff such as build system (CMake) and changing appropriate Unix syscalls to Windows ones in a #define. I have done a little research and found little on this topic, however. I know it is possible because I've seen it done with Bash. Visual Studio also used to do it when I ran a program in its GUI.
Reference article I got some of this info from: https://en.wikipedia.org/wiki/Win32_console
Note: What I mean is when you click on it and it opens it without running cmd in its own little console window. Or when you type it into cmd it opens in a separate window that isn't running cmd. I am assuming cmd.exe and the console window it runs in are two separate things, but if I am wrong, please let me know. :)
This question is inspired by https://askubuntu.com/questions/111144/are-terminal-and-shell-the-same and a similar question where I got that Wikipedia link. Someone said that the console window and the shell were separate. I was writing my own shell so I started to wonder how to make mine independent of the default one.
The Win32 Console and cmd.exe are two different things. Windows automatically opens a console window when a program that needs one is started. It decides whether do to so by switches hard-wired into the executable. This window will be running said program. If the program that started the process is running in a console window, the two programs will share that console window.
As Noodles said, it really is that simple. You just start it. Double-clicking on it will do it. The CreateProcess() function with CREATE_NEW_CONSOLE passed to it will do it. Running the program from cmd.exe with
start <command>
will do it.
There is also a family of functions in the Windows API, called FreeConsole() and AllocConsole() that will free a program from its current console and create a new console for it, respectively.
Reference link (given by Noodles): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).aspx

tkenv gui works, then doesn't under windows 7

OMNet++ v4.6. Windows 7 Professional.
I have been using the supplied omnetpp.cmd from \omnetpp-4.6\bin for over a month with success, after a few failures (null pointers in OMNet) the OMNeT Eclipse editor will start, but when running a simulation the Tkenv window will no longer appear.
I get the taskbar icon, but no window.
When I run OMNet++ using mingwenv.cmd which gives the bash shell, omnetpp works as expected.
I have rebuilt the OMNet++ 4.6 environment from the .zip file again with no improvement.
I deleted the .tklenvrc file for my simulation (as suggested in the "OMNET++ Tkenv/GUI doesn't appear anymore" question) but this has no effect. One could say, "Just use the bash shell" but I'd like to keep at a Windows level. Any ideas?
I would like to point out that the recommended way of running OMNeT++ simulations is to run them from mingwenv.
If you really have to run them from command prompt you must ensure that your path contains:
omnetpp_root/bin;omnetpp_root/tools/win32/usr/bin;omnetpp_root/tools/win32/mingw32/bin
Also be aware that <omnetpp_root>/bin/omnetpp.cmd is used to start the IDE while the simulations should be started from the mingwenv.cmd bash prompt. These two things are totally unrelated (i.e. the IDE and the simulations running in Tkenv)

Debugger command line arguments in Code::blocks

When debugging a program in Code::blocks, how do you specify command line arguments to be sent to the program being debugged. I can't find where to set this for the life of me and google searches bring up settings for debugging the compiler itself, rather than programs written in the compiler. It would be a strange thing to leave out.
Thanks,
Tim.
Ah, looking with a visual studio head on. It's not in the project settings dialog but off the project menu:
Project->Set Programs Arguments

simple gui based gdb debugging over ssh

I ssh into a linux VM which is setup remotely. I use Vim to write my code. For debugging however, I use netbeans through X11 which can sometimes be painfully slow. I tried using gdb buts its an efficiency killer. I love to hover over my variable and get to now their value rather that doing p variable_name , plus I like see and navigate through the code. Is there something light simple gui based debugging tool I can use. I have tried to use clewn http://clewn.sourceforge.net/ , but that doesnt work because it has a missing netbeans_intg feature. Is there any other similar vim gui based debugging tool ?
You can try ddd
which is a gui for gdb, I think it's lighter than netbeans.
cgdb is an interface to gdb but it is not a graphical one. It does not offer the possibility of hovering over a variable, but it shows you a window with the source code.
Well, I was in sort of your situation sometime ago, and you can have a look at my question about using gdb with remote sources.
First of all, your problem with netbeans_intg feature is related to vim which has been compiled with no support for it. If you can rebuild vim yourself, you can then enable it. Otherwise, as you can see in the answer that I gave myself to my question, you can leverage clewn's remote-vim capabilities.
In a nutshell, you can have a "local" vim (i.e. on a desktop/laptop machine presumably), which must still be built with netbeans_intg support, but now it is a vim under your complete control (i.e. it's on "your" machine), while clewn will run on the linux host where gdb and your debuggee will run.
You can then keep the source files on your desktop/laptop and have the remote clewn sort of "drive" your local vim to the proper source files while debugging.
IOW: clewn will get information out of gdb to know exactly which file/line you're into and connect to remote vim and tell it: "hey, go grab this file and show it around this line", highlighting current line, breakpoints etc.
This is a great solution for when you have far-away deployed systems and you need to debug them with minimum impact on the host where they are running, and presumably no option to transfer there all of your source files.
I don't know if this fits in any way with what you're trying to do, but it did really change things for me.
Hth,
Andrea.
Check out GDB server. Theoretcially, you should be able to start gdb on your linux machine in server mode and connect via GUI of your choice. As long as that GUI supports remote gdb connections, which Netbeans does.

Resources