0

I have an issue with my Ubuntu default terminal overwriting the current line when the prompt (specifically, the path that I am cding into) is quite large. I have closely followed the issue here: Terminal prompt not wrapping correctly and my problem is very similar, but unfortunately not the same.

Specifically, I have narrowed down the cause by commenting and uncommenting the .bashrc file and I have found the following lines to cause the problem:

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

Is there a specific way that I can fix it without commenting it wholly, since Ubuntu might know for which reason this is right there?

9
  • Depends on what you mean by "fix". Please edit your question and explain what the actual problem is. You just tell us it is similar to some other issue, but not the same. OK, so what exactly is the problem you are facing? Can you maybe add a screenshot so we can understand the problem? The line you show is where the prompt is being set up, commenting it will simply revert to a default prompt.
    – terdon
    Dec 22, 2020 at 17:37
  • @terdon I have described, albeit shortly, the issue: "overwriting the current line when the prompt ... is quite large"
    – user130907
    Dec 22, 2020 at 18:37
  • If you change PS1 to something simpler, do you get the same behavior? ie.PS1="[hostname] "'$LOGNAME:$PWD> ' There's a chance the special characters and variable expansions are messing things up. Try a simple PS1 and if it works, add back in your customizations one at a time and see which one is causing the problem.
    – mikem
    Dec 22, 2020 at 19:07
  • @mikem Just tried what you said, same issue arises.
    – user130907
    Dec 22, 2020 at 19:24
  • Is the shell launched within a GUI session, or are you coming in via ssh or some other remote protocol?
    – mikem
    Dec 22, 2020 at 19:37

1 Answer 1

0

I'm not sure why you would have gotten the same behavior when setting the PS prompt to something simple (ie PS1="[hostname] "'$LOGNAME:$PWD> ', but the problem goes away if you remove the .bashrc altogether.

To me, this indicates there is something else going on within your bashrc causing trouble.

My suggestion is to look into the variables you already have set, especially the ones you are using within your case block PS1 definition.

In your question, you state that your desired PS1 is user@host:dir. The PS1 definition you have written is overly complex, and incorrectly written as you try to add various colors and other unnecessary things.

Keep it to the basics. To get the prompt you state that you want, you really only need:

case "$TERM" in
xterm*|rxvt*)
    PS1="\u@\h:\w> "
    ;;
*)
    ;;
esac

Once you get that working, then you can add in all the colorful highlights and bells that you desire.

I've tried various mutations of the example you gave and could not produce the behavior you are describing. To dig into it more, we would need to see the complete bashrc, but I think you can work through it if you trim it down and only have the very basics until you get it working. Literally, delete everything in your bashrc except:

case "$TERM" in
xterm*|rxvt*)
    PS1="\u@\h:\w> "
    ;;
*)
    ;;
esac

and add back to it little by little. My bet is you have a control sequence buried in there somewhere that is throwing off the terminal in some way that we can't see in the short code snippet you provided.

3
  • So, the issue is actually quite different seemingly from the one I thought it was: in fact, the problem is due to non-English characters in my folder name where I cd into. Just tried a very long path name and this behavior of overwriting the current line didn't show up. It shows up only when the very long path name includes non-ASCII characters. Why could that be? I have read about something like that elsewhere, eg unix.stackexchange.com/a/468983, but not sure what the resolution / further investigation would be in my case, since the folder name is not something to be 'escaped'.
    – user130907
    Dec 24, 2020 at 19:14
  • Earlier you mentioned that the problem did not present itself when the .bashrc file was removed completely. Is this still the case for directories with non-ascii characters in their names? If so, then my guess would be that there is some conflict between the special characters you're using to change colors and the non-ascii characters. I'm not that familiar with the use of non-ascii characters in general, so maybe someone else can jump in and help us here.
    – mikem
    Dec 24, 2020 at 19:21
  • Yes, indeed, that's the case. I hope we find out a resolution...
    – user130907
    Dec 25, 2020 at 1:13

You must log in to answer this question.