tumbleweed: where the @*!'#|... is the system setting PS1 (prompt environment variable)
SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: UNK: (NEW Workstation) AMD 5900X w/64GB; CentOS 7 (Workstation) AMD FX 6300 w/32GB;
Posts: 74
Rep:
Yep, I followed your suggestion and found the forum group. No reply.
In the meantime I've been busy hacking /etc/bash.bashrc to see where in that cluster $#@* to start to look. If I find an area I mark it down and revert it back to its original form. A slow and painful process. I have located a potential candidate area as it took *some* of my hacks, but not all of them, which tells me I am in the right general area.
Tried doing an install zsh, and promptly came within a hair's width of toasting the install yet again. I ending up nuking anything that had zsh in the file name and hacking other things. Somehow it worked and I was at last able to access root again. This zsh is OUT for now so I am back to hacking BASH. I'd truly would like to string the person who developed /etc/bash.bashrc up by their thumbs... or devise some other torturous means to inflict PAIN on them! On the plus side they are not nearly -- but not by much -- as bad as the devils of KDE 5.x I truly would like to reserve a SPECIAL place in HELL for all of them!!
But maybe it is my mood after last night's Migraine Attack. OK it is time to go back to hacking. Hi Ho, Hi Ho, its back to Hacking I will go.
Distribution: UNK: (NEW Workstation) AMD 5900X w/64GB; CentOS 7 (Workstation) AMD FX 6300 w/32GB;
Posts: 74
Rep:
A very Quick followup: I [SOLVED] the problem!!! Well sort of... I was actually able to get my Custom BASH Prompt to take. You need to go all the way down to the line that reads:
*)
# With full path on prompt
PS1="${_t}${_u}:\w${_p} "
I simply commented that line out with a #. That way if the Experiment FAILED, it would be an easy fix of simply uncommenting the line out and saving the file.
Having commented the line out I simply cut and pasted my Custom Prompt below it:
I then SAVED the file, killed the konsole, then re-started the konsole and up popped custom color BASH prompt!
[cat@leopard~]/>
or
[root@leopard/]/>
So at least in THEORY the problem is [SOLVED] The PROBLEM that now remains is that I did ALL MY EXPERIMENTATION on the file /etc/bash.bashrc you know the file that begins:
"## PLEASE DO NOT CHANGE /etc/bash.bashrc There are chances that your changes
# will be lost during system upgrades. Instead use /etc/bash.bashrc.local
# for bash or /etc/ksh.kshrc.local for ksh or /etc/zsh.zshrc.local for the
# zsh or /etc/ash.ashrc.local for the plain ash bourne shell for your local
# settings, favourite global aliases, VISUAL and EDITOR variables, etc ...
I left my Custom Prompt in place but commented it out so I can find it once again, but then uncommented out the original script. That way no harm. no foul since the computer will not read the commented out lines anyway.
So NOW all I have to do if figure out all this silliness about using a file called /etc/bash.bashrc.local. Do I simply copy /etc/bash.bashrc => /etc/bash.bashrc.local? If so and I make my changes to the /etc/bash/bashrc.local file how does computer know to go look for that file, and NOT the /etc/bash.bashrc? A down-and-dirty method would be to give openSUSE the finger copy the original file to a backup location, then modify /etc/bash.bashrc then back *that* file up too, then if something happens simply rename or move the backup files back into place.
Hope this helps.
D'Cat
Last edited by desertcat; 07-20-2021 at 04:54 AM.
Reason: Bad typing skills posted the reply before I was ready.
The way I remember it, any /etc/*.local file acts as an appendage to it's "mother" file, so all you should need in /etc/bash.bashrc.local is your single prompt line. Any object in it that matches the mother gets ignored, so in your case, it's PS1, which manifests as environment variable $PS1 and a long, kaleidoscopic shell prompt.
Distribution: UNK: (NEW Workstation) AMD 5900X w/64GB; CentOS 7 (Workstation) AMD FX 6300 w/32GB;
Posts: 74
Rep:
Ah!! Thanks. I bet that is what the *) in /etc/bash.bashrc does.
My buddy suggested the exact same thing: All I need is the .local file with the Custom Prompt line in it.
Will try "experimenting" along those lines later tonight assuming no Monsoon storms move in triggering a massive Migraine attack, in which case it is off to take my Fiorinal, kill all light, and ride out the Migraine.
One trivia question: 1) I create a file called /etc/bash.bashrc.local and save it. 2) Do I need to chmod it to set permissions to match those in /etc/bash.bashrc or is there any easier way?
One trivia question: 1) I create a file called /etc/bash.bashrc.local and save it. 2) Do I need to chmod it to set permissions to match those in /etc/bash.bashrc or is there any easier way?
I don't believe the system cares what the permissions on /etc/*.local are, as long as they are readable by root:
Distribution: UNK: (NEW Workstation) AMD 5900X w/64GB; CentOS 7 (Workstation) AMD FX 6300 w/32GB;
Posts: 74
Rep:
Thank you. You have been a GREAT HELP. This has been a nightmare to solve. It is sooooo easy to modify every other distro I have tried, but not openSUSE 15.3 Leap. I'll let you know how this goes,
1) I created a file called /etc/bash.bashrc.local and made sure it was owned by root, and the permissions match yours.
2) I copied my prompt into /etc/bash.bashrc.local, saved it, closed all instances of konsole, then restarted console. I got the familiar white and red prompts. I then commented out the original BASH prompt that appeared in the *) saved, closed konsole and up popped my beautiful prompt.
So you were right about the * command. I noticed that you state, " I don't believe the system cares what the permissions on /etc/*.local. Instead of creating the file /etc/bash.bashrc.local, should I have created the file /etc/*.local? Since the *) comes before the bash command, does it break off when it finds the *) and looks for the file /etc/*.local?? which has the the single line with the custom prompt? We have so far proved the file /etc/bash.bashrc.local will run the prompt so long as the line that appears BELOW the *) which reads:
# With full path on prompt PS1="${_t}${_u}:\w${_p} " is commented out. If that line is NOT commented out I get the stock White and Red Prompts.
OK it is raining and I have started to have a migraine -- time to do my DRUGS, kill the lights and crawl in bed with the cat and go to SLEEP
I got rid of the red root prompt by commenting 4 lines in bash.bashrc:
Code:
# grep -A6 "prompting for root" bash.bashrc
# Other prompting for root
if test "$UID" -eq 0 ; then
# if test -n "$TERM" -a -t ; then
# _bred="$(_path tput bold 2> /dev/null; _path tput setaf 1 2> /dev/null)"
# _sgr0="$(_path tput sgr0 2> /dev/null)"
# fi
# Colored root prompt (see bugzilla #144620)
I've only given it a cursory test so far.
It might be worth a read of comment #25 and thereabouts in that bug.
Distribution: UNK: (NEW Workstation) AMD 5900X w/64GB; CentOS 7 (Workstation) AMD FX 6300 w/32GB;
Posts: 74
Rep:
Quote:
Originally Posted by mrmazda
I got rid of the red root prompt by commenting 4 lines in bash.bashrc:
Code:
# grep -A6 "prompting for root" bash.bashrc
# Other prompting for root
if test "$UID" -eq 0 ; then
# if test -n "$TERM" -a -t ; then
# _bred="$(_path tput bold 2> /dev/null; _path tput setaf 1 2> /dev/null)"
# _sgr0="$(_path tput sgr0 2> /dev/null)"
# fi
# Colored root prompt (see bugzilla #144620)
I've only given it a cursory test so far.
It might be worth a read of comment #25 and thereabouts in that bug.
Hummmmm VERY INTERESTING! A few lines below that you will see two lines that say _p="#" if you substitute say something like /> your prompt will now reflect /> rather than #.
For me I ended up cutting my teeth on IBM and MS_DOS and the > symbol became second nature. Though I have been hacking on Linux for ~ 21 + years I never did get use to $ and #, which lead me to barely touch PS1, to writing entire Custom Prompts both in BASH and ZSH using ACSII text colors. The question is did you blow up /etc/bash.bashrc which admonishes you to "PLEASE DO NOT CHANGE /etc/bash.bashrc..." ? BTW you can change the WHITE Prompt ~> by adding the ASCII sequence to something like _p="\[\033[1;36m\]/> " I think now changes that whole line into CYAN. By commenting out a SINGLE line and from that file and creating the file /etc/bash.bashrc.local that contains the Custom Prompt. Ideally IF you can create a file called /etc/*.local as /etc/bash.bashrc file is being read down from the top, when it reaches the *) line it then is diverted to /etc/*.local where the Custom Prompt can be found. For the time being just in case commenting OUT a line and is considered a major change, it is a good plan to have a copy of /etc/bash.bashrc original and a copy of your /etc/bash.bashrc.local stored some place just in case you get nuked, then you can copy back the original and modified files.
I've got to say we are hacking this horrible /etc/bash.bashrc into something reasonable.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.