tumbleweed: where the @*!'#|... is the system setting PS1 (prompt environment variable)

JZL240I-U · 04-20-2020, 10:35 AM

All is well with my --ahm tumbleweed's-- prompts in e.g. konsole. But I want to find where it is set during system start. Searching resulted in ~/.bashrc, /etc/bash.bashrc and a load others but none are setting PS1 to the used "\[$(ppwd)\]\u@\h:\w>". Anybody knows where (and how) it is done?

TB0ne · 04-20-2020, 11:18 AM

Quote:

Originally Posted by JZL240I-U

All is well with my --ahm tumbleweed's-- prompts in e.g. konsole. But I want to find where it is set during system start. Searching resulted in ~/.bashrc, /etc/bash.bashrc and a load others but none are setting PS1 to the used "\[$(ppwd)\]\u@\h:\w>". Anybody knows where (and how) it is done?

I use Tumbleweed, and system-wide it's /etc/profile. For my user it's in $HOME/.bashrc.

JZL240I-U · 04-21-2020, 07:15 AM

My system has no /etc/profile. There is an /etc/profile.d/ directory which contains files with bash-related names: "alias.bash" and "bash_completion.sh" both of which don't set PS1.

Nor is there any $HOME/.bashrc but an /etc/bash.bashrc which is not to be changed and there is no /etc/bash.bashrc.local.

Code:

# /etc/bash.bashrc for SUSE Linux
#
# 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
...
{snippet of code for bash}
...
	case "$(declare -p PS1 2> /dev/null)" in
	*-x*PS1=*)
	    ;;
	*)
	    # With full path on prompt
	    PS1="${_t}${_u}:\w${_p} "
#	    # With short path on prompt
#	    PS1="${_t}${_u}:\$(spwd)${_p} "
#	    # With physical path even if reached over sym link
#	    PS1="${_t}${_u}:\$(pwd -P)${_p} "
	    ;;
	esac

That is not what I find when I issue an "echo $PS1" which gets me "\[$(ppwd)\]\u@\h:\w>". Any further ideas?

piscikeeper · 04-21-2020, 07:33 AM

Have you tried creating the file by copying /etc/bash.bashrc to /etc/bash.bash.bashrc.local and then making changes to .local ?

TB0ne · 04-21-2020, 07:44 AM

Quote:

Originally Posted by JZL240I-U

My system has no /etc/profile. There is an /etc/profile.d/ directory which contains files with bash-related names: "alias.bash" and "bash_completion.sh" both of which don't set PS1. Nor is there any $HOME/.bashrc but an /etc/bash.bashrc which is not to be changed and there is no /etc/bash.bashrc.local.

Sorry, don't know what to tell you then. I am using Tumbleweed on several systems, and I have an /etc/profile file, and in my home directory there is my .bashrc. Both of them have PS1 defined, and in my .bashrc, I have SUDO_PS1 defined. Both work fine.

Quote:

That is not what I find when I issue an "echo $PS1" which gets me "\[$(ppwd)\]\u@\h:\w>". Any further ideas?

Create a .bashrc file in your home directory??

mrmazda · 04-28-2020, 04:41 AM

TW has been migrating /etc/ to be a place only for admin files, not distro defaults. I wouldn't have been surprised to see nothing in /etc/ to copy to /etc/bash.bashrc.local, but it is there, and I do see PS1 strings in /etc/bash.bashrc starting 65% into the file. I can't read scripts well enough to see whether it should produce what you see, but when I do echo $PS1 as root, I get '\[\]\h:\w #\[\]'. As ordinary user it produces '\u@\h:\w>'.

ehartman · 04-28-2020, 08:09 AM

Quote:

Originally Posted by JZL240I-U

My system has no /etc/profile. There is an /etc/profile.d/ directory which contains files with bash-related names: "alias.bash" and "bash_completion.sh" both of which don't set PS1.

There should be, unless you once deleted it, because IT is the one that sources all /etc/profile.d/*.sh scripts:

Code:

# Append any additional sh scripts found in /etc/profile.d/:
for profile_script in /etc/profile.d/*.sh ; do
 test -x $profile_script && . $profile_script
done
unset profile_script

(from my /etc/profile script (Slackware).

From 'man bash'

Quote:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

so bash doesn't look into /etc/profile.d at all unless /etc/profile does do that for it.

And your local user's profile is in ~/.bash_profile, .bash_login, and ~/.profile, in that order and (TBone) not in ~/.bashrc.
If they do not exist you can create them and set your own private PS1 string in there.

petelq · 04-28-2020, 09:26 AM

I put this line in my own .bashrc file

Code:

export PS1 = '\U \W >'

and it works once you log out/in or reboot. That's my preference, of course and you put what ever you want in the single quotes as I'm sure you know.

JZL240I-U · 05-19-2020, 12:27 PM

I looked into these files again. My current understanding is now that /etc/bash.bashrc is the culprit where the system gets its PS1. They are working with variables in the file though (e.g. "PS1="${HOST}:"'${PWD}'" # ""). That is why I didn't see the same as what "echo $PS1" produced.

Here is more explanation of SUSE's:

Code:

me@PC:~> cat /etc/skel/.bashrc
# Sample .bashrc for SUSE Linux
# Copyright (c) SUSE Software Solutions Germany GmbH

# There are 3 different types of shells in bash: the login shell, normal shell
# and interactive shell. Login shells read ~/.profile and interactive shells
# read ~/.bashrc; in our setup, /etc/profile sources ~/.bashrc - thus all
# settings made here will also take effect in a login shell.
#
# NOTE: It is recommended to make language settings in ~/.profile rather than
# here, since multilingual X sessions would not work properly if LANG is over-
# ridden in every subshell.

test -s ~/.alias && . ~/.alias || true

Reason for all this is that I want to have my manjaro PS1 same as SUSE's PS1. They do it differently though and I don't understand enough of their script to change it. Giving up...

desertcat · 07-10-2021, 01:21 AM

Quote:

Originally Posted by piscikeeper

Have you tried creating the file by copying /etc/bash.bashrc to /etc/bash.bash.bashrc.local and then making changes to .local ?

Well I am glad I am not the only one scratching my head. I've been running most of the RH distros -- Fedora, Red Hat (OLD), Mandrake (OLD), and currently CentOS (5,6,7, and now 8)and I have hacked /etc/bashrc, and have created a stylish prompt, so I know if I am running in root or in home -- showing the entire PATH. I am currently evaluating Open SuSE 15.3 LEAP as a possible replacement for CentOS. I am sure have heard that when CentOS 8.xy dies there will be NO CentOS 9. The two OS's on the short list are Rocky Linux and Open SuSE 15.3 Leap. My buddy and I are seriously considering Open SuSE 15.3 as the default GUI is KDE, while Rocky Linux (and CentOS) are a bug for bug copy of RHEL.

The first thing I tried to do in Open SuSE is to modify the prompt in /etc. The first shock came when I discovered that there is NO /etc/bashrc, but DID FIND a /etc/bash.bashrc. The second shock was the opening lines PLEASE DO NOT CHANGE /etc/bash.bashrc... Instead use /etc/bash.bashrc.local. There is, of course, no /etc/bash.bashrc.local so I simply copied /etc/bash.bashrc and saved it as /etc/bash.bashrc.local, and then modified that file and added my custom PS1 command, saved the file and rebooted. DISASTER!! I was no longer able to login, and my buddy gave me a hand so I could access root, ran mc, and DELETED my /etc/bash.bashrc.local file and rebooted. Now I am back to where I started, but at least I am able to login.

SuSE is STRANGE: Perhaps someone can illuminate me?

1) What is this "... .local" file? There are no ".local" files. When I COPIED /etc/bash.bashrc and appended "... .local" to it, my machine had a fit.

2) What is this /etc/profile which we are admonished NOT TO CHANGE, as well as the non-existent /etc/profile.local?

Here is my CentOS prompt in the file /etc/bashrc (no /etc/bash.bashrc):

[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="\[\033[1;32m\][\[\033[1;33m\]\u\[\033[1;36m\]@\h\[\033[1;31m\]\w\[\033[1;32m\]]\[\033[1;35m\]/>\[\033[1;37m\]"

3) Assuming that I was correct by copying /etc/bash.bashrc => /etc/bash.bashrc.local perhaps someone can tell me WHERE exactly in that file I should copy the above prompt statement in that enormous file. If not COPY what do I need to MODIFY in that statement to make it work? Obviously I did not do something right, as by machine threw a hissy fit.

Any HELP would be greatly appreciated.

mrmazda · 07-10-2021, 03:01 AM

Quote:

Originally Posted by desertcat

The first thing I tried to do in Open SuSE is to modify the prompt in /etc.

It's openSUSE, always, dumb, I know, but you'll never see it otherwise on any installed openSUSE system or any openSUSE web pages, except where it explains its spelling and case, or maybe for some archived pages from v10.0 &/or v10.1. No small number will ignore pleas for help from those who don't use the official spelling.

openSUSE by default sets root's prompt foreground color red, while white/gray for dark backgrounds and black for light backgrounds, and shows fullpath, and login name, so tells me all I need to know from a prompt. If I see ~ in a prompt, and no red either, I know I'm not root. So, openSUSE's prompts have not had reason to catch much interest from me since I learned they could be changed, sometime last century, long pre-SuSE.

/etc/bash.bashrc.local is like /etc/profile.local, and /etc/systemd/system/local-after-boot.service, and /etc/systemd/system/local-after-boot.timer, optional, existent only where an admin created it. bash.bashrc.local I don't use. The first of the others I've used since around SuSE Linux 8.2 or so. My oldest backup of profile.local, with only a umask line in it, is 16 years old. My current one has three lines in it, written 4 years ago. These optional files are supposed to contain only differences from, or additions to, defaults, so there's no reason for them to exist in a fresh installation.

desertcat · 07-10-2021, 04:32 AM

Quote:

Originally Posted by mrmazda

openSUSE by default sets root's prompt foreground color red, while white/gray for dark backgrounds and black for light backgrounds, and shows fullpath, and login name, so tells me all I need to know from a prompt. If I see ~ in a prompt, and no red either, I know I'm not root. So, openSUSE's prompts have not had reason to catch much interest from me since I learned they could be changed, sometime last century, long pre-SuSE.

Yep I discovered this. I try to AVOID RED Text. While RED is my favorite color, RED TEXT is hard for me to read. GREY is also hard for me to read. Hacking prompts using ASCII code has been one of my "things" ever since I learned it in IBM/MS-DOS 4.0. I have only messed with SuSE a few times and right now I am evaluating openSUSE

but my knowledge of it is non-existent. After some 20+ years of exposure to RH, trying to customize a prompt in SuSE or openSUSE (

) seems to be near impossible. I thought writing a prompt in zsh was tough. But I don't have a CLUE where to begin here. You mentioned that you learned that prompts could be changed. WHERE and HOW?

Quote:

Originally Posted by mrmazda

/etc/bash.bashrc.local is like /etc/profile.local, and /etc/systemd/system/local-after-boot.service, and /etc/systemd/system/local-after-boot.timer, optional, existent only where an admin created it. bash.bashrc.local I don't use. The first of the others I've used since around SuSE Linux 8.2 or so. My oldest backup of profile.local, with only a umask line in it, is 16 years old. My current one has three lines in it, written 4 years ago. These optional files are supposed to contain only differences from, or additions to, defaults, so there's no reason for them to exist in a fresh installation.

So, if I read your post correctly, you don't use /etc/bash.bashrc.local; also, again if I read your post correctly, you use profile.local?? Would you know if I can install oh-my-zsh!on openSUSE 15.3? IF so I might to work around the prompt confusion by installing oh-my-zsh! and then installing one of a gazillion custom prompts. Still but that will be a lot of work just for an OS evaluation. Bashrc would be "good enough" for these purposes if I could figure out where to cut and paste my custom bash prompt.

A final question -- for living life on the Wild Side -- could I simply copy my /etc/bashrc file from CentOS and copy it into openSUSE 15.3?? or is SUSE so messed up it would not read the /etc/bashrc file... or worse cause SUSE to have a spectacular meltdown? Any help yopu copuld provide would be appreciated.

mrmazda · 07-10-2021, 04:51 PM

Quote:

Originally Posted by desertcat

Yep I discovered this. I try to AVOID RED Text. While RED is my favorite color, RED TEXT is hard for me to read. GREY is also hard for me to read. Hacking prompts using ASCII code has been one of my "things" ever since I learned it in IBM/MS-DOS 4.0. I have only messed with SuSE a few times and right now I am evaluating openSUSE

but my knowledge of it is non-existent.

Rather than trying to improve readability with colors, I decided long ago to pretty much stick to sizing. On the ttys that means 1280x720 or 1440x900 on a 1920x1080 or 1920x1200 screen. I played with custom prompts on DOS back in the 1980s too. I don't have any more recollection of that than I do for shell prompts, and haven't found where I last messed with them. I did find the following in my .bashrc template used on Debians:

Code:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

Where it came from I have no idea. More than likely I copied and pasted somewhere, and tried it on openSUSE, without success.

/etc/bash.bashrc.local
profile.local
Would you know if I can install oh-my-zsh!on openSUSE 15.3?

1: no; 2: yes; 3: no idea. If it comes packaged as an rpm, it should be installable at least. If not, try extracting and testing in /usr/local/ohmyz/ or so if it's a standalone app. Whether workable, who knows?

If you haven't read /etc/skel/.bashrc, it might be worth it as a guide to how bash and shell configuration works on openSUSE. Surely it should be on https://doc.opensuse.org/ somewhere in more detail.

I wouldn't mess with prompt configuration anywhere in /etc/ without first figuring out how it works on a per user basis. cf. https://forums.opensuse.org/showthre...28#post2198228

Sorry I can't be more helpful. Maybe asking on openSUSE's own forums or mailing lists would find someone knowledgeable on this subject.

desertcat · 07-10-2021, 09:35 PM

Quote:

Originally Posted by mrmazda

Rather than trying to improve readability with colors, I decided long ago to pretty much stick to sizing. On the ttys that means 1280x720 or 1440x900 on a 1920x1080 or 1920x1200 screen. I played with custom prompts on DOS back in the 1980s too. I don't have any more recollection of that than I do for shell prompts, and haven't found where I last messed with them. I did find the following in my .bashrc template used on Debians:

Code:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

Where it came from I have no idea. More than likely I copied and pasted somewhere, and tried it on openSUSE, without success.

/etc/bash.bashrc.local
profile.local
Would you know if I can install oh-my-zsh!on openSUSE 15.3?

1: no; 2: yes; 3: no idea. If it comes packaged as an rpm, it should be installable at least. If not, try extracting and testing in /usr/local/ohmyz/ or so if it's a standalone app. Whether workable, who knows?

If you haven't read /etc/skel/.bashrc, it might be worth it as a guide to how bash and shell configuration works on openSUSE. Surely it should be on https://doc.opensuse.org/ somewhere in more detail.

I wouldn't mess with prompt configuration anywhere in /etc/ without first figuring out how it works on a per user basis. cf. https://forums.opensuse.org/showthre...28#post2198228

Sorry I can't be more helpful. Maybe asking on openSUSE's own forums or mailing lists would find someone knowledgeable on this subject.

Thanks!! You have been more than helpful. I have to start somewhere. Will try to find openSUSE's forums. Great idea.

In other news... I just blew up SUSE this morning while trying to install some program -- I toasted it good!! I am doing a complete new install even as I type this. IF -- BIG IF -- I can hack KDE 5.xy.z -- and I am very, very, close -- assuming I can solve the prompt problem -- promptly !! -- openSUSE 15.3 will rise to the top of the Candidates file. Right now SUSE is a learning experience with a STEEP learning curve. Then it will be on to Rocky Linux 8.4 Stable.

I've still have several hacking days ahead of me with openSUSE. The question remains how many more times will I nuke SUSE before I get the hang of it. Again thanks for your help.

D'Cat

JZL240I-U · 07-19-2021, 07:12 AM

The openSUSE forums are here: https://forums.opensuse.org/ HTH.

P.S.: Funny, I got no message that there were new posts in this thread *head scratch* ...