I know in gdb, I can set
break 14
To break at line 14, this is the "1" break point, then
commands 1
printf "%d\n",i
end
This will attach gdb commands to break point 1. No problem.
But my question is: seems commands are co-exist with break point, as I use "i b" to check its information. In the case above:
How can I remove the commands from break point 1, and still keep the break point?
How to list/filter all commands information, without search all break points information?
Thanks.
You can remove the commands from a breakpoint by entering an empty command list:
commands 1
end
will remove the commands from breakpoint 1.
As far as I know there's no way to list or filter the breakpoint commands other than looking at the output of info breakpoints.
Related
Note: I am running Mac OS X Sierra but this problem occurs on Ubuntu also.
I have customised the terminal prompt as such:
export PS1="\n\[\033[1;31m\]\u 🖖 \[\033[1;32m\]# \[\033[1;32m\]\h \[\033[0;35m\]in \[\033[0;36m\]\w\n\[\033[0;34m\]> \[\033[1;37m\] \e[0m"
Note that I have put a newline at the end, so I start typing commands on a new line after the >. I have done this on a number of machines, and I've noticed that whenever I add the newline, the terminal behaves weirdly.
By weirdly, the exact behaviour I refer to is this (this includes the steps to replicate the error if you use the PS1 value I have mentioned):
Access older commands by pressing the up arrow key.
When I encounter a command in the history which consists of more than 1 word, and the first word is is more than 4 characters long, then the first 4 characters of the word 'stick' to the initial part of the prompt.
This 'sticky part' cannot be deleted by me, and does not even go when I press the up arrow key several more times.
For instance, if the last 4 commands I entered were (from least recent to most recent): clear, man man, this that and help.
Then, when I look at previous commands by pressing the up key incrementally:
help is visible properly.
this that is visible properly.
Note how this is appended at the start. I cannot delete it if I try.
Continues to stay as I press the up key.
How can I resolve this issue?
Each of the escape-sequences in your prompt has to be bracketed with \[ and \] to tell bash that those characters should be ignored for the purpose of counting columns. The last one in your example is not bracketed:
export PS1="\n\[\033[1;31m\]\u 🖖 \[\033[1;32m\]# \[\033[1;32m\]\h \[\033[0;35m\]in \[\033[0;36m\]\w\n\[\033[0;34m\]> \[\033[1;37m\] \e[0m"
i.e., \e[0m
If you fix the error, bash is likely to give better results. This shows the suggested correction;
export PS1="\n\[\033[1;31m\]\u 🖖 \[\033[1;32m\]# \[\033[1;32m\]\h \[\033[0;35m\]in \[\033[0;36m\]\w\n\[\033[0;34m\]> \[\033[1;37m\] \[\e[0m\]"
This question is motivated by Jenkins jobs, and their Execute shell build step. Jenkins by default calls sh with -x switch, which results in echoing the commands it executes. This is definitely good and desired behaviour. However, it would be very nice to be able to just print messages nicely, in addition to having the set -x in effect. An example follows:
If there is echo Next we fix a SNAFU in the build step script, console output of the build will have
+ echo Next we fix a SNAFU
Next we fix a SNAFU
It would be much nicer to have just single line,
Next we fix a SNAFU
How to achieve this? Solution is ideally general sh solution, but Jenkins-specific solution is fine too. And solution should be quite nice looking in the shell script source too, as the dual purpose of the echoes is to both document the script, and make the output more clear.
So just surrounding every echo like that with
set +x
echo Message
set -x
is not very good, because it will print + set +x before every message, and it also takes up 3 lines in the script.
set +x
<command>
set -x
This will disable the printing of the <command>
I found two solutions, neither is ideal but both are kind of ok.
I like better this first one. Instead of having echo Message, have
true Message
It will display
+ true Message
This works, because true ignores its command line arguments (mostly). Downside is the + true clutter before message, and possibly confusing use of true command for others who read the script later. Also, if echo is turned off, then this will not display the message.
Another way is to do echo like this:
( set +x;echo Message )
which will print
+ set +x
Message
This works, because commands in () are executed in a subshell, so changes like set don't affect the parent shell. Downside of this is, it makes the script a bit ugly and more redious to write, and there's an extra line of output. Also, this spawns an extra subshell, which might affect build performance slightly (especially if building under Cygwin on Windows). Positive is, it will also print message if echo is off, and perhaps intention is immediately clear to those who know shell scripting.
I want to record the register changes using watch command in gdb which is like this:
(gdb) watch $register-name
gdb stop whenever the register changes in the application and I have to press c to continue debugging. Is there any way to instead of hitting enter for endless time, I just ask gdb to save all the changes in the register to a file?
I have to press c to continue debugging.
Note that pressing <Enter> will repeat previous command (e.g. previous c).
Is there any way to instead of hitting enter for endless time, I just ask gdb to save all the changes in the register to a file?
Sure:
(gdb) watch $rax
Watchpoint 2: $rax
(gdb) commands 2
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>c
>end
# This is to prevent stop after every screen-full of output
(gdb) set height 0
(gdb) set logging on
Copying output to gdb.txt.
(gdb) continue
Voila: you now have all the changes in gdb.txt
Setting a watchpoint using (lldb) watchpoint set var myvar will pause the program whenever the variable is written to and print out the change of value to the debugging console.
From using this in the Xcode GUI, I know that it is possible to set breakpoints that execute an action and automatically continue the program afterwards.
Is a similar behaviour possible with watchpoints? Can I set a watchpoint that only prints the change and automatically continues the program execution afterwards?
I actually used a solution close to what Jason described above. It worked for me in XCode 6 and is described in details there: In XCode 6 how can you set a watchpoint without stopping execution?.
Hope this helps.
You're looking for the watch command add command in lldb. The watchpoint commands are not as mature / tested as the breakpoint commands in lldb -- I just did some quick tests and what you want to do doesn't work right now with Xcode 6. Ideally you'd do something like watchpoint command add --script-type command -one-liner "continue" or watchpoint command add --script-type python -one-liner "return True" (of course the shortest unambiguous command can be used, e.g. wa c add -e python -o "return True", I'm spelling out the full commands to be clearer). When you add a command to a watchpoint it doesn't look like the "old value / new value" output is produced. I don't think that should be its current behavior but I'll ask a few other people to see if they strongly disagree.
I'd like to have a blank line after my bash prompt and before the output on my Mac. It should look like this would:
echo; ls
Can I add a newline to my bash prompt and then go back up one line to wait for user input? Is there something obvious I'm missing?
I know this is old but for someone like me who came across this while googling for it. This is how you do this...
It's actually pretty simple!
Check out this link --> Cursor Movement
Basically to move up N number of lines:
echo -e "\033[<N>A HELLO WORLD\n"
Just change the "< N >" to however many lines you want to go back...
For instance, to move up 5 lines it would be "/033[5A"
To my knowledge this is not possible unless you delve into more low-level stuff like full-screen emulators like curses.
This is a bit of a stab in the dark, but you may be able to use VT102 terminal codes to control the cursor without having to use Curses. The relevant VT102 commands that you'd be interested in all consist of sending ESC, then [, then the specific command parameters.
For instance, to move the cursor up one line, one needs to output:
ESC [ 1 A
0x1B 0x5B 0x31 0x41
Be warned that the VT102 documentation generally uses octal, so keep an ascii table handy if you're using hex.
All of this advice is given without having tested it -- I don't know if VT102 commands can be embedded into your bash prompt, but I thought it might be worth a shot.
Edit: Yeah -- looks like a lot of people use VT102 formatting codes in their bash prompts. To translate my above example into something Bash would recognize, putting:
\e[1A
into your prompt should move the cursor up one line.
This is very possible. If your bash has C-v set as the readline quoted-insert command, you can simply add the following to your ~/.inputrc:
RETURN: "\C-e\C-v\n\C-v\n\n"
This wil make bash (readline, actually) insert two verbatim newlines before a regular interpreted newline. By default, only one is inserted, which is what causes output to start on the line after the prompt.
You can test if C-v is set to quoted-insert by typing it in bash (that's Ctrl+V) followed by e.g. an up arrow. This should print ^[[A or something similar. If it doesn't, you can bind it in ~/.inputrc too:
C-v: quoted-insert
RETURN: "\C-e\C-v\n\C-v\n\n"
~/.inputrc can be created if it doesn't exist. The changes will not take effect in running bashes unless you issue a readline re-read-init-file command (by default on C-x C-r). Be careful though. If you do something wrong, enter will no longer issue commands, and fixing your mistake could prove to be difficult. If you should do something wrong, C-o will by default also accept the line.
Adding a newline followed by moving the cursor back to the regular prompt (like you described) is possible, but will not have the effect you intend. The newline you inserted would simply be overwritten by the application output, since you moved the cursor back in front of it.
This works:
trap echo DEBUG
It doesn't add an extra newline if you hit return at an empty prompt.
The command above will cause a newline to be output for every member of a pipeline or multi-command line such as:
$ echo foo; echo bar
\n
foo
\n
bar
To prevent that so that only one extra newline is output before all command output:
PROMPT_COMMAND='_nl=true'; trap -- '$_nl && [[ $BASH_COMMAND != $PROMPT_COMMAND ]] && echo; _nl=false' DEBUG
The DEBUG trap is performed before each command so before the first command it checks to see if the flag is true and, if so, outputs a newline. Then it sets the flag to false so each command afterwards on the line doesn't trigger an extra newline.
The contents of $PROMPT_COMMAND are executed before the prompt is output so the flag is set to true - ready for the next cycle.
Because pressing enter on an empty command line still triggers the execution of the contents of $PROMPT_COMMAND the test in the trap also checks for those contents as the current command and doesn't perform the echo if they match.
I believe (but haven't tried) if you put '\n\b' in the prompt string it would do that.
In general, if you want to find out the codes to do anything a terminal can do, read the terminfo man page.
In this case, the cursor up one line code can be determined by:
tput cuu1
If you redirect the tput output to a file, you can see what control characters are used.
Bash also supports the PROMPT_COMMAND variable, allowing you to run arbitrary commands before each prompt is issued.