When I am in a shell like bash, if I use the up arrow to go through the command-line-history buffer, it behaves in a predictable way: hitting up goes to the command I executed most recently.
In the Windows cmd.exe ("DOS") shell, sometimes hitting the up arrow goes to the most recent command, sometimes it goes to the 2nd most recent command or even the 3rd most recent command. Sometimes, to get to the most recent command I entered, I actually have to hit the down arrow! Sometimes I have to hit the down arrow twice!
What is the logic to this? It's been driving me batty for a long time.
The command selected by up/down-arrow is relative to the last-selected repeat.
So if you have executed
line 1
line 2
line 3
line 4
Then pressing up-arrow 3 times and enter would reselect and execute line 2
From there, you can down-arrow once to re-select line 3 or twice for line 4 or up-arrow once for line 2, twice for line 1
BUT the new lines executed are appended to the list and if you enter a line manually, the selector moves to the bottom of the list again.
The line will not be entered into the list if it is a duplicate of the last entry, so you can up-arrow-and-execute a thousand times if you want to and up-arrow-twice will get the (-1001st) command entered.
Related
I am trying to understand VS Debugging Techniques.
Situation 1:
I have a 100 line of code. I have break point as 10,20,30,40. Currently my debugger is at line 20. And Now I realize that I want to go to line 50 (Kindly note that I DO NOT HAVE any breakpoint there). So I click on line 50. So is there any way I can go to line 50. P.S: I don't want to skip the execution of previous lines. I want the debugger to execute till line 49 properly w/o stopping at any previous breakpoint and stop at line 50. Is it possible?
Situation 2:
I have a 100 line of code. I have break point as 10,20,30,40. Currently my debugger is at line 20. And Now I realize that I want to go to line 40 (Kindly note that I do HAVE A breakpoint there). So I click on line 40. Is there any way I can go to line 40. P.S: I don't want to skip the execution of previous lines. I want the debugger to execute till line 39 properly w/o stopping at any breakpoint and stop at line 40. Is it possible?
Please guide me if it's possible. And you could tell me keyboard shortcut too that will be awesome.
P.S: If any of the situation 1 or 2 is possible I can live with that as that will be huge help to me. If I can click on a line then I can always put a breakpoint (no laziness) provided I know that I can directly reach to that line ignoring all the previous breakpoints :)
i don't understand why sometimes the CUB sequence is allowed to continue through the previous line and sometimes not. the documentation tells it's not but in real situation...
http://vt100.net/docs/vt100-ug/chapter3.html#CUB
for exemple i have a screen filled with spaces on 80 columns and 24 lines.
i am at position line 3, column 4 which can be set with escape sequence : \033[3;4H
i move the cursor on the left 10 times with sequence \033[10D
wich will put me at position : line 2 column 76
so it worked ?!!
and sometimes it doesn't
please save me ! :)
I can reduce the situation but this is where i saw it :
I'm writing a vt* emulator and everithing works fine. i can launch emacs/vim and others but then i launched vttest in putty with the "script" command to record every typed characters and sequences. like so :
# script test
Script started, file is test
# vttest
...
when i do "cat test" in putty for exemple, it replays everythings like i did. when i play it with my emulator i am able to parse and to analyse every escape sequence they provide, but the display is not the same.
The wording on VT100.net is fairly clear:
If an attempt is made to move the cursor to the left of the left margin,
the cursor stops at the left margin.
In a recent discussion, someone pointed out that PuTTY honors a (non-VT100) capability bw, which quoting from ncurses' terminfo manual:
auto_left_margin bw bw cub1 wraps from col‐
umn 0 to last column
PuTTY's behavior for wrapping at the margins differs from VT100s, as you have seen. ncurses has a terminal entry named "putty", simply because PuTTY differs from all of the other terminals enough to make using a nuisance otherwise.
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.
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.
Say I am in a bash terminal and have a large history of commands. I pressed the up arrow a whole bunch of times and am in the "middle" of the history. I want to now navigate to the first or the last command in my history quickly (without holding down the up or the down arrow for a long time). Is this possible? If so, what is the shortcut key to achieving this?
Take a look in the man page:
man bash
Here I copied for you the thing you were looking for:
previous-history (C-p)
Fetch the previous command from the history list, moving back in the list.
next-history (C-n)
Fetch the next command from the history list, moving forward in the list.
beginning-of-history (M-<)
Move to the first line in the history.
end-of-history (M->)
Move to the end of the input history, i.e., the line currently being entered.
Depending on how things are set up for your terminal, you can usually do a Ctrl+C to break you back to the beginning (no comment) and then go up once or twice to get to the recent command you want.
Alternatively, using the history command will list all the recent commands used with index values associated with them. !# where # is the index number will rerun that command. There's a nice usefulness of the command history | grep [command] to try and find a specific command in your history.