[Solved] Minor bash problem.

mobius · 2024-02-11 20:35:48

Hi. I'm having a minor issue, which I believe is with bash, and wondering if anyone can provide some confirmation.

I am using (all are the latest available from the Salix repos):
bash 5.1.016-x86_64-1
in xfce4-terminal 1.0.4-x86_64-1gv
on Xfce 4.18.0-x86_64-1gv
on Salix 15
in VirtualBox 7.0.12 r159484 (Qt5.15.2)
on Windows 10

The problem is that, at the command line, when moving backward through the history with the Up-arrow key, sometimes the command line does not clear completely but leaves perhaps the first 15 to 20 characters of that command displayed, so that all of the following commands start following those residual characters.

As an example, I can reproduce it like this:
In your home directory, at the command line, issue the command:
$ cat .config/xfce4/terminal/accels.scm

Next, issue a few other commands, such as ls -al, or whatever you like.

Now, using the Up-arrow key, step backwards through your history. Each previous command should display correctly, up to and including the previous cat command. But the next Up-arrow command will leave the characters 'cat .config/xfce4/' at the beginning of the command line, immediately followed by the previous command. And successive Up-arrow commands will continue to show the previous commands following those stuck characters, which never clear.

This has been bothering me for a while. At first, I thought it might be a problem with xfce4-terminal. But, I've been experimenting with some other terminals, and noticed that it was happening in them, also.

So, in a new Tab in xfce4-terminal, I ran zshell, and cannot seem to reproduce the problem there, by which I suspect that the problem is with bash.

Can anyone reproduce this behavior?

Last edited by mobius (2024-02-13 19:52:56)

mobius · 2024-02-12 21:15:02

So I tried running bash in xfce4-terminal on PCLinux, and on MX-Linux, and neither displayed the problem. And yet it is 100% reproducible for me on Salix. Any suggestions for further trouble-shooting?

ToZ · 2024-02-13 00:23:32

Maybe it has something to do with the bash configuration files like bashrc? Perhaps there is some configuration there that is affecting it. Can you post your Salix ~/.bashrc file? Or alternatively, test it in the other environments.

mobius · 2024-02-13 17:44:09

You are right! Renaming .bashrc and restarting terminal, the problem disappears; restoring .bashrc returns the problem. So I started at the top of the file to eliminate sections, until the problem disappeared. Here is the complete file:

# bash configuration file.

# Set up prompt.
# default = export PS1='\u[\W]\$ '
export PS1='\n\e[1;35m\u\e[1;36m[\w]\e[0m\$ '

# Set up pager.
export PAGER=/usr/bin/most

# Set up the LS_COLORS environment:
if [ -f $HOME/.dir_colors ]; then
  eval `/bin/dircolors -b $HOME/.dir_colors`
elif [ -f /etc/DIR_COLORS ]; then
  eval `/bin/dircolors -b /etc/DIR_COLORS`
else
  eval `/bin/dircolors -b`
fi

# Set up LS_OPTIONS environment variable.
# This contains extra command line options to use with ls.
# The default ones are:
#  -F          = show '/' for dirs, '*' for executables, etc.
#  -T 0        = don't trust tab spacing when formatting ls output.
#  -b          = better support for special characters
# --color=auto = colorize directory listings 
export LS_OPTIONS="-F -b -T 0 --color=auto --group-directories-first"

# Set up aliases.
if [ -f ~/.bash_aliases ]; then
  source ~/.bash_aliases
fi

And the problem went away when I removed the PS1 line, which is very strange! I tried the statement with both singe and double quotes, which made no difference. Do you see anything wrong with that line?

mobius · 2024-02-13 17:54:20

So further experimentation has shown that the problem arises whenever any colour codes are used in PS1. Huh? Shouldn't that be allowed?

Edit: Further, I tried replacing the \e sequences with \033, but it made no difference.

Last edited by mobius (2024-02-13 18:05:54)

ToZ · 2024-02-13 19:32:04

Try the following PS1 prompt:

export PS1='\[\e[1;35m\]\u\[\e[1;36m\][\w]\[\e[0m\]\$ '

It removes the first "\n" and properly embeds the color codes in the square brackets. I think the first "\n" is interfering with the line wrapping.

mobius · 2024-02-13 19:52:03

Genius! It works as expected, without the issue popping up. Thank you.

Next, I tried putting the newline back, and that also worked okay, so it must be the brackets around the colour codes. Strange, in all my MetaGer'ing about colours in Linux, I never came across that necessity, but I'm sure it must be documented somewhere. smile

ToZ · 2024-02-13 19:54:05

mobius wrote:

Next, I tried putting the newline back, and that also worked okay, so it must be the brackets around the colour codes. Strange, in all my MetaGer'ing about colours in Linux, I never came across that necessity, but I'm sure it must be documented somewhere.

Interesting. Thanks for letting me know.

mobius · 2024-02-13 20:07:20

Just to bring closure to this, I found this question on StackExchange: https://unix.stackexchange.com/question … ps1-prompt.

The first (very long) answer by @goldilocks describes the problem exactly (read down past the colour charts), and gives the solution of bracketing the colour codes in the prompt, so that they are not counted as part of the length of the prompt -- you nailed it!

Xfce Forum

Sub domains

#1 2024-02-11 20:35:48

[Solved] Minor bash problem.

#2 2024-02-12 21:15:02

Re: [Solved] Minor bash problem.

#3 2024-02-13 00:23:32

Re: [Solved] Minor bash problem.

#4 2024-02-13 17:44:09

Re: [Solved] Minor bash problem.

#5 2024-02-13 17:54:20

Re: [Solved] Minor bash problem.

#6 2024-02-13 19:32:04

Re: [Solved] Minor bash problem.

#7 2024-02-13 19:52:03

Re: [Solved] Minor bash problem.

#8 2024-02-13 19:54:05

Re: [Solved] Minor bash problem.

#9 2024-02-13 20:07:20

Re: [Solved] Minor bash problem.

Board footer