When debugging a function (which has been marked debug using debug("f"), the debugger gives you the Browser prompt which also tells you at what line number in the program you are. If run a couple of test statements at the prompt (to check variables, etc.) the screen scrolls and I no longer know what line number I am at (using SecureCRT so it scrolls past the buffer). The command where only tells you what function you are in. Does anyone know how to get the actual line number and next statement to be executed?
Thanks
When I use the regular browser(), I set max.lines to print to a low number:
options(deparse.max.lines=100)
so that if the output during debugging is long, I don't have to scroll too far up.
Related
You want to view the return information of the last command from the beginning, because that information is relatively long. If I look for it manually, it will be very troublesome. So if I want to quickly go back to where typed last time,.
There are alternatives, of course
Use "less" or "more" program to make the message shorter
Use the history function to re-enter the command
However, the two solutions have their own problems."less" and "more" are not provided in the PowerShell, and they need to be provided additionally. In addition, sometimes the command has been executed and cannot be added "less" or "more" again. If you re-enter the command, you may not get the same result as last time.
It can't be found in the' cursor movement functions' of 'psreadline'. You can't find the result by Google searching for 'PowerShell return to last input position'.
It seems that this demand is very basic. Is there really no way to realize it?
You can easily set a watchpoint in XCode by following these steps (btw if there is a simpler way, I'd like to know it...):
- Run your program
- Set a breakpoint in the code where your variable is used
- when reaching breakpoint, use a right click on the variable and select 'Watch "nameOfTheVariable"'
- Continue execution.
The only problem is that execution will stop every time the variable value changes. I would like XCode to continue the execution without stopping, i.e. merely display the value changes in the console output.
This feature seems available in command line mode, and although I initially wanted to avoid it, I posted a solution using that mode (see below), as it seems to be the only way to do what I want, i.e. continue execution while displaying variable changes.
Well it seems that the only way to achieve this is to use the LLDB command line. So for those of you who, like me, had never used it here is a step-by-step (actually fairly easy) way to use it and watch variables without stopping execution:
Set a breakpoint in Xcode (click to the left of your source line) where the variable you want to watch is used (in scope), and run your code until it reaches the breakpoint.
In the console view (little window displayed at the bottom right where you can display console things) you should see a (lldb) prompt. This is where you enter the following commands:
w s v stuff (or watchpoint set variable stuff) where stuff is the name of the variable you want to watch
w c a (or watchpoint command add) to enter a script mode where you enter one command per line as follows after the '>'
p stuff (or print stuff) to display the new stuff variable value
c (or continue) to continue execution
DONE to finish this little script (note the UPPERCASE characters!)
THAT'S IT ! You can remove your breakpoint and continue execution. From then on messages will be displayed in the console every time the variable "stuff" is updated, without stopping the execution of your code (it might slow it down a little of course, but that is usually not important).
Watchpoint is just like a breakpoint which gets hit when the value of a variable which is being watched gets updated.
To set it please follow below steps:
1.Set a breakpoint such that the variables view in the debugger shows the variable you want to watch.
2.Right click on the variable and select Watch "variable name".
3.This will stop the execution whenever the value of the variable changes.
The watchpoint will now start showing in the debug navigator.
In order to remove it just drag is towards the editor and you are good to go.
PS : this is just a smarter version of implemention didset for a variable and setting and breakpoint inside it.
I'm using expect scripts to reconfigure a bunch of Cisco routers. Mostly, its working well, I have a file of addresses that is read by a script, which passes the addresses, one at a time to another script that logs on, goes into enable mode, then pulls a series of router configuration commands from a test file, which it issues to the router.
That worked well until I tried to script the logon banner. In this process, you issue the router a command line with a delimiter character, then follow that with whatever you want to have as a banner, formatted as you want to see it, then finish the banner off with a second delimiter character.
That gives a problem: when you move from one line to the next (with C/R) when building the banner, each new line starts with just a blank line (unlike a successful command, which will open a new line with #). That means that expect has no trigger to let it know to place the next line of banner, so it hangs.
I've tried things with embedded "\n" and "0x0a" to no avail.
has anyone any suggestions? has anyone succeeded in doing this before?
OK, I fixed it. Expect is waiting for the # prompt before it provides the next line. If you end each line of the banner with a #, it works, even though the C/R and # are round the wrong way. It may not be the most tidy programming but it works
While debugging some code in gdb, I want to see which line will be executed if I say next or step.
Of course I can say l, but if I say l a couple times (and don't remember how many times), then l does not print the line that will be executed.
I can also scroll back to the last time gdb stopped and see which line it was at, but that sometimes involve digging through a bunch of output.
I am wondering if I am missing a simple command in gdb which shows me the current line the debugger is stopped at?
To see the current line the debugger stopped at, you can use frame command with no arguments. This achieves the same effect as update command. It works both in tui and command line mode.
You can use
list *$eip
or the shorter form
l *$eip
This will instruct gdb to print the source lines near the current program counter.
You can say l +0; the current line will be the first one listed.
The command l +offset lists the code starting from offset lines from the current line.
Note that, if you have already used the list command, the current line will have changed, i.e., it will no longer be the next executing line. So this will only work on your first list command.
It sounds like you want to run GDB in Emacs (which will show you current file and mark the current line), in DDD, or in tui mode.
I'm writing a command interpreter like BASH, and a \ followed by a newline implies a continuation of the input stream; how can I implement that in Win32?
If I use the console mode with ENABLE_LINE_INPUT, then the user can't press backspace in order to go back to the previous line; Windows prevents him from doing so. But if I don't set ENABLE_LINE_INPUT, then I have to manually reposition the cursor, which is rather tedious given that (1) the user might have redirected the input stream, and that (2) it might be prone to race conditions, and I'd rather have Windows do it if I can.
Any way to have my newline and eat it too?
Edit:
If this would require undocumented CSRSS port requests, then I'm still interested!
Assuming you want this to run in a window, like command prompt does by default, rather than full screen, you could create a GUI application with a large textbox. Users would type into the textbox, and you could parse whatever was entered, and output to the same box (effectively emulated the Win32 Console).
This way whatever rules you want to set for how the console behaves is completely up to you.
I might be mistaken is saying this, but I believe that the Win32 Console from XP onward works exactly like this, and it just listens for output on stdout; there shouldn't be any reason you can't do the same.
Hope this was helpful.