Custom prompt stopped working in KDE apps

Storm · 2017-01-01 10:58:51

I have a custom prompt set in my etc/bash.bashrc (set there and not in home to make it global).

After a recent update the custom prompt part stopped working in Konsole and Dolphin (which may actually use Konsole for its built in terminal, not sure). My aliases in the same file still work, only custom colors don't. It also still works on tty, just not in Konsole/Dolphin.

I'm asking this on KDE forums too, but in my experience I get much better help at Arch forums, even in KDE related things.

Here is my bashrc: http://pastebin.com/ZZBXMgXg

Rob_H · 2017-01-01 16:39:18

I had a problem like this once and it turned out to be a bug in my PS1 setting. I'm not gonna debug yours, sorry. I'd suggest going back to a basic prompt and then incrementally add back in your embellishments to figure out which one is breaking the terminal.

thunderstone · 2017-01-03 20:25:57

After updating my arch today I had the same problem. It turned out that my /etc/DIR_COLORS was not uptodate (missing TERM xterm-256color).

Storm · 2017-01-04 18:00:25

Rob_H wrote:

I had a problem like this once and it turned out to be a bug in my PS1 setting. I'm not gonna debug yours, sorry. I'd suggest going back to a basic prompt and then incrementally add back in your embellishments to figure out which one is breaking the terminal.

It's not the prompt setting. And it worked for a year... see blow

thunderstone wrote:

After updating my arch today I had the same problem. It turned out that my /etc/DIR_COLORS was not uptodate (missing TERM xterm-256color).

I don't have an etc/DIR_COLORS nor ~/.dir_colors and I never did. It uses defaults if none of those files are defined.

I just did some testing (previous I did it incorrectly) and found that what happens is this: My bashrc has this IF:

# Check if we have color support
if [[ $'\n'${match_lhs} == *$'\n'"TERM "${safe_term}* ]] ; then

################ Enable colors...

else
        # Else set colorless prompt
 
        ### Setting the prompt
    PS1="\u@\h \w \$([[ \$? != 0 ]] && echo \"[X] \")\$ "
 
fi

The else path gets executed. I changed the prompt there, and that reflects.

So the question is, why does my IF fail, while it worked previously?

Last edited by Storm (2017-01-04 18:18:35)

svnset · 2017-01-04 18:12:34

When it works in tty and not in Konsole/Dolphin it sounds more like a color related issue here. Are you using xterm or xterm-256color in Konsole?

Storm · 2017-01-04 18:19:53

svnset wrote:

When it works in tty and not in Konsole/Dolphin it sounds more like a color related issue here. Are you using xterm or xterm-256color in Konsole?

Just edited my post, previously I screwed up testing but now I did it right and got a step closer. I hoped I can edit it before anyone sees it. O-o

Please check the edited post above, and sorry for the inconvenience!

Last edited by Storm (2017-01-04 18:20:37)

Storm · 2017-01-04 18:34:51

OK based o above posts something related to colors changed in Arch?

thunderstone wrote:

After updating my arch today I had the same problem. It turned out that my /etc/DIR_COLORS was not uptodate (missing TERM xterm-256color).

I don't have /etc/DIR_COLORS and according to what I've read Arch is not supposed to have one by default. I never customized the colors, only the prompt so it makes sense I don't have one.

Or did it now become mandatory to have it for colorization to work?

svnset wrote:

Are you using xterm or xterm-256color in Konsole?

No idea... I don't know what those mean.

This is the relevant part of the bashrc script I took from someone a year ago and customized:

# sanitize TERM
safe_term=${TERM//[^[:alnum:]]/?}
match_lhs=""
 
# Check for color definition files
[[ -f ~/.dir_colors ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"
[[ -z ${match_lhs} ]] \
    && type -P dircolors >/dev/null \
    && match_lhs=$(dircolors --print-database)
# Check if we have color support
if [[ $'\n'${match_lhs} == *$'\n'"TERM "${safe_term}* ]] ; then

The IF at the end fails.

(Full bashrc: http://pastebin.com/ZZBXMgXg )

Last edited by Storm (2017-01-04 18:35:09)

svnset · 2017-01-04 18:54:22

So there you have your problem. I assume you did not write your bashrc by yourself...? You should ask another question, why do you have this if statement in the first place.. Checking for color support can be done more easy... I think you can fix it by yourself now. Consider changing this part of your bashrc or at least try to understand it.

Storm · 2017-01-06 09:38:31

svnset wrote:

So there you have your problem. I assume you did not write your bashrc by yourself...?

As pointed out above, took one from someone else - one that was highly recommended by several people and even the Arch wiki itself, and modified the prompt formatting only.

svnset wrote:

You should ask another question, why do you have this if statement in the first place.. Checking for color support can be done more easy... I think you can fix it by yourself now. Consider changing this part of your bashrc or at least try to understand it.

I have no idea, and no I can't fix it because I don't understand it. Telling me that it can be done a better way but without giving any clue is not helping, it just feels elitistic.

Not everyone using Arch is a Linux god. I use Arch because it's just a thousand times better than any other distro I have tried or seen, and because I love the freedom it gives. But I can't afford to spend thousands of hours on learning everything Linux, so I expand my knowledge as I run into problems to solve.

If you want to help, and point me in the right direction, that would be great, but the "I'm not going to tell you because you should figure it on your own" attitude is really not nice.

Last edited by Storm (2017-01-06 09:43:58)

Trilby · 2017-01-06 12:03:19

Storm wrote:

I have no idea, and no I can't fix it because I don't understand it.

That's why you shouldn't have used it in the first place. Looking at examples is good - but you should learn what those examples are doing and incorporate that into your own configs. Copying and pasting large blocks of code you don't understand is a recipe for disaster regardless of the source.

As for the rest of your post, you're going a bit off the rails. There was nothing remotely inappropriate in svnset's post - it did point you in a right direction that you should remove all of that and create it again yourself if/when you understand what you are adding to the file. That is good advice. It may not be complete advice but that doesn't mean it is bad nor "elitistic" (btw, that's not a word).

It would be perfectly reasonable for you to ask a follow-up question of svnset for guidance about sources to learn to write a better bashrc. But getting pissy with someone who was trying to help you is foolish. If you keep that up, no one will bother helping you.

Here's a great bash guide which is also linked from our wiki.

If you have questions about things you learn there ask. If you want feedback on a draft of a bashrc section you wrote, ask. If you want someone else to do your thinking for you and just give you code to copy and paste without learning, then you are in the wrong place.

svnset · 2017-01-06 12:24:04

Sorry when I gave you this feeling.. Still here in the forums we will stick to the do it yourself approach. I did not mean to say this bashrc is bad. I meant it's bad that you use something, not knowing what is actually happening there, because your global bashrc is very important..

crikey · 2017-01-19 03:30:27

Had the exact same problem as Storm: bash prompt in KDE lost color after a recent update. Turns out I was using the same section of dodgy code sourced from an example bashrc recommended in the wiki a few years ago.

For the benefit of people with the same problem who would appreciate a quick fix: remove the various unnecessary 'if' statements and replace with

# Matches "xterm-color", "xterm-256color", etc.
if [[ ${TERM} == *"color"* ]]; then

Seems to work successfully for me. Don't know why the original example used such a convoluted test.

Trilby · 2017-01-19 03:38:51

Or you can just test the output of `tput colors`. Or really, you can take what you know of your system that you set up. I know that on my system, the part of my bashrc that have my prompt is only every parsed by interactive sessions on terminals that are either 256 color capable, or have TERM="linux", so my conditional just checks that TERM != "linux".

Arch Linux

#1 2017-01-01 10:58:51

Custom prompt stopped working in KDE apps

#2 2017-01-01 16:39:18

Re: Custom prompt stopped working in KDE apps

#3 2017-01-03 20:25:57

Re: Custom prompt stopped working in KDE apps

#4 2017-01-04 18:00:25

Re: Custom prompt stopped working in KDE apps

#5 2017-01-04 18:12:34

Re: Custom prompt stopped working in KDE apps

#6 2017-01-04 18:19:53

Re: Custom prompt stopped working in KDE apps

#7 2017-01-04 18:34:51

Re: Custom prompt stopped working in KDE apps

#8 2017-01-04 18:54:22

Re: Custom prompt stopped working in KDE apps

#9 2017-01-06 09:38:31

Re: Custom prompt stopped working in KDE apps

#10 2017-01-06 12:03:19

Re: Custom prompt stopped working in KDE apps

#11 2017-01-06 12:24:04

Re: Custom prompt stopped working in KDE apps

#12 2017-01-19 03:30:27

Re: Custom prompt stopped working in KDE apps

#13 2017-01-19 03:38:51

Re: Custom prompt stopped working in KDE apps

Board footer