I change my gdb prompt's color by writing set prompt \033[1;33m(gdb) \033[0m into .gdbinitfile. And I change my gdb prompt's color sucessfully.
But I find that my long command with my parameters will overwrite my prompt after I input a long command without going to newline. Why?
Edit: if your gdb has python scripting enabled, look at #matt's answer to see how to do this using the set extended-prompt command - it's a better solution.
Gdb manages command input by using the readline package. The way to tell readline that a character sequence in a prompt string doesn't actually move the cursor when output to the screen is to surround it with the markers RL_PROMPT_START_IGNORE (currently '\001' in readline's C header file) and RL_PROMPT_END_IGNORE (currently '\002').
Bash has a portable way of expressing this: when it sees "\[" and "\]" in the prompt variable, it will convert them to RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE. Bash does this while it's processing various other escape sequences such as \w to include the current working directory.
Gdb's set prompt command doesn't support "\[" and "\]", but you can put the octal escapes \001 and \002 in your set prompt string (subject to change if readline's authors ever choose to use a different set of markers).
set prompt \001\033[1;33m\002(gdb) \001\033[0m\002
gdb has a command: set extended-prompt that accepts escape sequences described in the gdb.prompt python module. which includes the \[ and \] bashism's for wrapping characters that do not contribute to the prompts length. This of course requires a python enabled gdb to work though.
How do I fix this? I don't want to change my server name I just want to customize the text here (no server name, still shows path/user). Also what's this section of the terminal window called?
The Terminal Entry line prefix is called the shell prompt.
You can generally find the current config by typing
echo $PS1
That returned this for me: [\e]0;\u#^C\w\a]${debian_chroot:+($debian_chroot)}\u#\h:\w\$
So I was able to remove the "#\h" in both locations and get the desired tag.
export PS1="\[\e]0;\u: \w\a\]${debian_chroot:+($debian_chroot)}\u:\w\$ "
leaving me with "root:/kliq$'
I have a default installation of vim on linux, on a system with a vt52 terminal emulator and unicode capability.
Everything has been working fine until today when I moved my vt52 terminfo file from the temporary local user directory to the permanent system directory ... at first it seemed fine, but all the sudden, when I try to execute a colon command by pressing enter (either CTRL-J, or the key itself == decimal 10), vim just flashes the screen but doesn't execute the command or leave command entry mode.
However, If I press CTRL-M to get a carriage return character (decimal 13), vim does accept the command.
I tried copying the file back to ~/.terminfo again, but it didn't fix the problem...
I thought this might be either a tty issue or a corrupted vimrc file, so...
first I tried deleting the .viminfo and .vimrc files, and doing a stty sane before starting vim but neither helps. I just noticed that enter doesn't work in insert mode either, but CTRL-M does.
Then I checked from the bash shell, using CTRL-V, that when I press CTRL-M, it shows ^M and when I press CTRL-J, it just enters and shows nothing. So -- to double check -- I did a stty raw and cat - | hexdumpx, and sure enough pressing enter returns only 0x0a, and pressing CTRL-M returns only 0x0d ; so the keyboard driver is returning the proper character in raw mode, and I retested in sane mode which apparently maps both of them to 0x0A.
The termcap file I re-compiled with tic, and copied to both ~/.terminfo/v/vt52u where it worked fine before -- and over to /usr/share/terminfo/v/vt52u.
But I don't see anything in the termcap file which could possibly cause the problem.
vt52u|vt52 with UTF-8:\
:am:eo:rs=\Ee\Eb0\Eco:is=\EE\Ee:\
:nl=^j:sr=\EI:bl=^g:ta=^i:\
:ho=\EH:cr=^m:le=\ED:nd=\EC:do=\EB:up=\EA:ta=^i:nw=^j^m:xn:\
:cm=\EY%+ %+ :it#8:co#75:li#24:\
:sc=\Ej:rc=\Ek:\
:vi=\Ef:ve=\Ee:\
:so=\Eb0\Ec3:se=\Eb0\Eco:mh=\Eb8\Eco:mr=\Ebo\Ec0:me=\Eb0\Eco:\
:cl=\EH\EJ:cb=\Eo:cd=\EJ:ce=\EK:\
:km:kb=^h:
EDIT:
I've isolated the problem by experiment 5 listed below, as being caused by something either in or missing from the above termcap file, or in the tic compiler's conversion of it to terminfo.
So -- what termcap entry is missing or which existing one is causing the problem?
---------------------- Additional experiments as I try to figure it out -------------------
1: doing a :set term in vim reveals term=vt52u .... which is correct. So VIM should be using the above termcap file, but I don't know from where (eg: cached version, or not -- or corrupted.) and :version only reveals +termcap which says vim should be using a tic compiled termcap file which is what I've been trying to give it.
2: I recompiled ncurses-5.9, and re-installed it to make absolutely sure no corrupt files exist. Nothing changed even with: ./configure --prefix=/usr --without-cxx --without-cxx-binding --without-ada --without-manpages --without-progs --without-tests --with-build-cc=gcc --with-shared --without-debug --without-profile --without-gpm --without-dlsym --without-sysmouse --enable-sigwinch --enable-hashmap --enable-scroll-hints --build=i686-linux --host=arm-linux-gnueabi --without-pthread --enable-widec --with-fallbacks=vt52u --disable-big-core --enable-termcap --enable-getcap-cache
3: doing a :set termcap shows more keys defined than the termcap file has, which is bad... termcap only defined one key ... and that one should be ^H not ^?, so VIM's value doesn't match, but the other termcap values all match, since ^[ is the same as escape \E in the termcap file. So, I have proof that vim is definitely loading the proper termcap file because t_so 's value is unique to the vt52u. So -- it's not a corrupt termcap.... :( weird.
t_kb <BS> ^? <DecMouse> ^[[
t_kd <Down> ^# <NetMouse> ^[}
t_sr=^[I t_bc=^[D t_le=^[D t_cd=^[J t_ce=^[K t_cl=^[H^[J
t_me=^[b0^[co t_mr=^[b0^[co t_ve=^[e t_vi=^[f t_nd=^[C t_se=^[b0^[c0
t_ZH=^[bo^[c0 t_ZR=^[b0^[co t_so=^b0^[c3 t_cm=^[Y%p1%' '%+%c%p2%' '%+%c
4: Recompiled vim 7.4, to remove all built in terminals, and to insure no corrupt files. Had no effect; did not fix default value of backspace key being wrong.
echo "Please Edit feature.h so that NO_BUILTIN_TERMCAPS is always #defined."
sleep 5
vim /src/feature.h
./configure --prefix=/usr/ --build=i686-linux --host=arm-linux-gnueabi --with-features=big --disable-darwin --disable-selinux --disable-xsmp --disable-xsmp-interact --disable-mzschemeinterp --disable-tclinterp --disable-netbeans --disable-sniff --disable-gui --disable-cscope --disable-workshop --enable-multibyte --disable-gtktest --disable-gpm --disable-sysmouse --disable-xim --enable-pythoninterp=dynamic --without-x --with-tlib=ncursesw vim_cv_toupper_broken="yes" vim_cv_terminfo="yes" vim_cv_tty_group="world" vim_cv_tty_mode="0620" vim_cv_getcwd_broken="yes" vim_cv_stat_ignores_slash="yes" vim_cv_memmove_handles_overlap="yes"
echo "Please Edit src/Makefile such that STRIP=arm-linux-gnueabi-strip"
sleep 5
vim src/Makefile
make
make install
5: In bash, I changed the terminal type to generic "export TERM=VT52" rather than the unicode version, with color support which I compiled with tic. ** THE NEWLINE PROBLEM WENT AWAY WITH THE SACRIFICE OF COLOR COMMANDS, AND OTHER FEATURES OF VT52U ** I need the features, but apparently something about the termcap file I listed above is defective.
This was an ugly bug to track down by trial and error...
Vim appears to require keydown to be defined, and if not defined it assumes a default value of ^# ; for an unknown reason, it then treats the enter key as if it were a key down, rather than newline. ^# is logically the value for character code 0, null; which is the only character that would be found in an empty string in "C" which vim is written in and appears to trigger the issue/feature/bug.
But in any event in the termcap shown in the opening post, the kd symbol is not defined; and that's what is causing the problem.
Within vim, the problem can be solved by setting the termcap keydown variable as the same escape sequence which would normally exit insert mode, and then do letter j (down):
:set t_kd=\Ej
The same default can always be added to the termcap entries, too;
Since this is an input escape sequence and not a terminal output escape sequence, it doesn't conflict with the VT52's "save cursor" escape sequence defined in the termcap; eg: The VT52 will never see it since Linux tty's when in line entry mode do not echo escape sequences that come from the keyboard back to the terminal's output.
If a terminal doesn't have true arrow keys -- defining the arrow keys as escaped versions of vim's h,j,k,and l keys might be a reasonably compatible solution as long as it doesn't conflict with other programs which might want to use those input escape sequences for other things. I don't use emacs and other popular programs which might want those escape sequences for something, so if anyone else knows which (if any) programs would have problems with that solution, a comment would be appropriate.
In ncurses 5.9,there appears to be a bug in the terminfo compiler, so that on many installations (eg: slackware 14), 'tic' will not be able to compile terminfo source files -- but only termcap source files. If you want the termcap source code for an arbitrary terminal, you can run "infocmp -C fooTerminalName > fooTerminalName.tcap" to have the system generate a termcap source file for you that can be edited and recompiled with tic successfully.
I can't find a way to display bash special chars. For example the hostname is \h.
If I do :
echo '\h \\h'
it won't work ( display h \h). How can I make it display my hostname ?
ref : http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/bash-prompt-escape-sequences.html
Those are only evaluated in the PS1 and PS2 variables. You can test them dynamically like this:
PS1="\h"
The bash will then display the new prompt. Just open a new bash if you mess it up, it will not be saved.
The HOWTO told you it is "Prompt Escape Sequences", only works when you put then in PS1 or PS2,
My xterm $prompt variable in my .tcshrc is:
set prompt="%{\033]0;%m:%~\007%}%{^[[;37;1m%}%B%{^[[;34;1m%}%m%{^[[;34;1m%}:%b%c%# "
The highlighted part above (%{\033]0;%m:%~\007%}) puts the hostname (%m) and the current directory (%~) in the title bar. (At least I think that that's what puts it in the title bar; it's been a while since I fiddled with this prompt).
When I run screen, however, the current directory stops getting updated when I change directories.
My questions:
How can I make this prompt work in screen?
Is there a better way to display the current directory in the title bar?
I am running linux with xterm and tcsh.
I think there is no direct way, because of the way screen works. However screen can display its own status bar, that you can define in .screenrc. Here's mine for instance :
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%=%{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]'
Firstly, to make it work you must check where exactly is the line with set prompt=blah-blah in your .tcshrc. For example, the code below that perfectly works in plain xterm would not work under screen in xterm:
switch ($TERM)
case "xterm*":
set prompt="%{\033]0;${HOME:t}#%m:%l:%c08\007%}%{\033[36m%}%l:%c02%#%{\033[0m%} "
# update xterm title to display current cmd in it
alias postcmd 'echo -n "\033]0;${HOME:t}#`hostname`:${tty} \!#:q\007"'
...
because screen by default sets $TERM variable to screen and not xterm! So you must add:
case "screen":
# lame, but prevents an error in screen after 'su - root'
if (! $?WINDOW) setenv WINDOW 1
set prompt="%{\033]0;${HOME:t}#%m:${WINDOW}:%c08\007%}%{\033[36m%}%c02%#%{\033[0m%} "
alias postcmd 'echo -n "\033]0;${HOME:t}#`hostname`:${WINDOW} \!#:q\007"'
...
Secondly, make sure yo have this line in ~/.screenrc:
termcapinfo xterm* 'hs:ts=\E]2;:fs=\007:ds=\E]2;\007'