1

I set a custom PS1 to expand the current directory. That works well, however, the text input does not match the PS1 length. Instead of the input being at the ">" I set at the end of PS1, it is instead only about 10 characters in from the line start. This only happens when I'm inputting a fair amount of text on the command line (especially recalling previous long commands or pasting). If the text is short, everything works fine.

A lot of other weird stuff happens too, most often when the command being input requires a newline.

Is there something I missed when configuring .bashrc ?

Here is my PS1. 'CurDir' is a variable I set to print out the current directory (PWD if small, or a cut version if long). Most of the colors were from someone else. Only 'CurDir' was added by me and is set earlier in .bashrc.

PS1='\e[1m\[\u@\h \]\e[0;36m\[$CurDir\]\e[m>'
jktstance
  • 143
  • 2
  • 7
  • It depends ;) What exactly does your `PS1` look like? If you use just `\w \$` or `\W \$`, you shouldn't have any problems. If you include non-printing characters (like terminal escape codes for colours), then you might run into trouble if you don't escape them with `\[...\]`. Impossible to tell without seeing your `PS1`, though. – Benjamin W. Mar 10 '20 at 19:24
  • 1
    See, for example, [this question](https://stackoverflow.com/q/342093/3266847). – Benjamin W. Mar 10 '20 at 19:26
  • The question has been updated with the PROMPT_COMMAND line. – jktstance Mar 10 '20 at 21:33

1 Answers1

2

You escaped the wrong parts: \[...\] is used to wrap the unprinted parts of the prompt.

Your escaping:

PS1='\e[1m\[\u@\h \]\e[0;36m\[$CurDir\]\e[m>'
            └─┬──┘            └──┬──┘
            escaped            escaped

Escaping the unprinted parts:

PS1='\[\e[1m\]\u@\h \[\e[0;36m\]$CurDir\[\e[m\]>'
       └─┬──┘         └───┬──┘           └─┬┘
       escaped        escaped             escaped

This assumes that there are no terminal escape codes in $CurDir.

Benjamin W.
  • 46,058
  • 19
  • 106
  • 116
  • Thanks. This prompt command was working in an older linux session I had up, but with a new update, no such luck. Or maybe there was a switch in the terminal type used. I will try this out tomorrow and update the answer then. – jktstance Mar 12 '20 at 01:32