2

Well, I think you know pretty well what I'm talking about; if not, check this video. Basically, when you press your up array to obtain the previous command, often the characters are left on the terminal. Is there any way to circumvent the problem?


EDIT: This problem doesn't happen with gdb only, but also with a normal terminal. This should be the interesting lines in .bashrc

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

EDIT2: Ok, I'll try to explain it with an example. Suppose you have this terminal history (pretty simplified for the sake of simplicity):

user:host$>cd foo/bar
user:host$>sudo apt-get dist-upgrade
user:host$>clear
user:host$>

Then, if you press your up arrow key 3 times, you are expecting something like

user:host$>cd foo/bar

but you are obtaining instead

user:host $>sudo apcd foo/bar

This is the least funny scenario you can end up with, I must admit; sometimes there are a so complex mosaico on the screen that you want to crash anything. I don't know which is the cause, I think I probably bad formatted something in the .bashrc file, but still I don't know what.

However, changing the previous .bashrc lines to something like this

if [ "$color_prompt" = yes ]; then
    PS1='\[\033[1;31m\]\u:\[\033[1;37m\]\W\\$>\[\033[0;32m\]'
    PS2='\[\033[1;37m\]>\[\033[0;32m\]'
else
    PS1='\u:\W\\$'
    PS2='>'
fi

the problem partially disappears: it's not happening anymore in normal shell, but if I launch gdb for example it happens most of the time. Can it be related to the special characters?


EDIT3 Here are the relevant lines in ~/.gdbinit file; you can find the whole file here. Maybe the final \] string is missing, isn't it?

 if $USECOLOR == 1
    # BLACK
    if $arg0 == 0
        echo \033[30m
     // a lot of other if-else conditions
  • 1
    What is your prompt set to, and how? I'm not familiar with gdb's way of setting the prompt, but it uses readline, and readline expects escape sequences (e.g. switching to red) to be enclosed within \[ and \], or \x01 and \x02 (not sure which), omitting these is a typical problem with color bash prompts that leads to pretty much the same behavior as seen in this video. – egmont May 13 '16 at 22:23
  • @egmont see the edit – tigerjack89 May 14 '16 at 4:59
  • There are way too many things happening in the video and we can't see the keys you press. Could you please describe with words one particular buggy behavior (keypresses, actual vs. expected behavior)? I'm not sure what your problem exactly is. – egmont May 14 '16 at 6:18
  • @egmont Well, it's not too easy to explain, but I thought the problem was common because I've seen it in so many videos. Btw, read the new edit. – tigerjack89 May 14 '16 at 8:23
  • 1
    There's no sign of \[ and \] whatsoever in the file you linked. I've probably missed to double-escape these chars, e.g. try \\[, \\] or something along these lines. You should try \001 and \002 too, probably readline requires these. – egmont May 17 '16 at 20:53
1

In bash's primary prompt ($PS1) all non-printable characters (e.g. escape sequences that change the color) have to be enclosed between literal \[ and \].

Similarly, for all other readline-based apps, such as gdb, non-printable characters in the prompt need to be enclosed between a 0x01 and a 0x02 byte. You can refer to these in .gdbinit as \001 and \002.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.