[SOLVED] Why does PS1 get unset when I run X Windows / KDE?
SlackwareThis Forum is for the discussion of Slackware 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.
Another simple example is that a profile might do PATH=$PATH:/somewhere and you wouldn't want that run for every additional terminal window you pop-open as it would result in duplicates in the path.
This can not and will not happen, because in "/etc/profile":
Code:
# Set the default system $PATH:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games"
This can not and will not happen, because in "/etc/profile":
Code:
# Set the default system $PATH:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games"
Yes, fair point.
As long as /etc/profile explicitly sets path to an absolute value that won't happen: that was a bad example.
However, if we allow for the possibility that profile only contains a PATH=$PATH:/somewhere statement (maybe because the admin decided to rely on the base PATH being set some place else — ENV_PATH in login.defs, PAM, or /etc/environment as examples — then the point would stand. Admittedly, that's stretching a little, but it's a possibility, so the argument can still be made, if only on a conceptual level.
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447
Rep:
Quote:
Originally Posted by GazL
As long as /etc/profile explicitly sets path to an absolute value that won't happen: that was a bad example.
I still think the overall point stands, considering there are scripts in /etc/profile.d that set the path by adding directories. gawk, qt5, z-dot-in-non-root-path and the kde scripts all do it that way.
Last edited by pghvlaans; 09-25-2021 at 03:27 AM.
Reason: clarification
@pghvlaans:
The scripts in "/etc/profile.d/" are called from "/etc/profile" only. After the initial "PATH=...".
So nothing strange can / will happen, unless you call the scripts in "/etc/profile.d/" from other places.
So the choice to use a login shell or not is up to the user. Safely.
I am addressing this purely from a technical standpoint by looking at the relevant scripts in "/etc/".
@GazL:
Code:
LANG=some_locale.utf8 xterm +ls &
Quote:
+ls
This option indicates that the shell that is started should not be a login shell (i.e., it will be a normal “subshell”).
I guess my point is that instead of telling the user what they can or can not do, most programs have plenty of command line options to change their behavior to suit your needs.
If users want to start every shell as a login shell, let them. There's nothing wrong with that.
And to get back on-topic...
Developers should leave that choice to the user and not force their opinions onto the user - Konsole does not have a simple checkbox to choose if you want to start the shell as a login shell or not. That I have a problem with.
Konsole does not have a simple checkbox to choose if you want to start the shell as a login shell or not. That I have a problem with.
Konsole 21.08.1, the version currently in Slackware64-current, allows you to edit the "Command" property, which defaults to /bin/bash, in any Konsole "profile" other than the default profile. So you can create a new Konsole profile and in that profile add a -l argument to the bash invocation to get a login shell (which is an odd thing to call a shell that does not require you to login, but whatever). Then you can change that new profile to be the default profile.
One tip: The Konsole profile config/editing facility in the app is a bit of a cluster ****. The trick is to, in the "Settings" drop-down menu, skip the first option, "Edit Current Profile". That's a trap. Skip the second "Settings" drop-down menu option, "Switch Profile". That's a distraction. Navigate down to the last option in the "Settings" drop-down menu, "Configure Konsole" (it's all so intuitive!). That brings up a nice config screen with "Profiles" being the second iconified tab option. Click that and now you can add, delete and edit Konsole profiles and set one of them as your default profile.
Except, when you do that, you're back to not having all your aliases and PS1 defined: which was the very issue that prompted people to set their terminals to login-shells in the first place
Having your PS1 and aliases in ~/.bashrc and then letting .bash_profile call that still seems the least problematic approach to me.
So the choice to use a login shell or not is up to the user. Safely.
No, the option (to use login shell) is created for a reason. Login shell is only used when the user logs in - by design. The user has right to forget/ignore it and misuse it.
Quote:
Originally Posted by MadMaverick9
Developers should leave that choice to the user and not force their opinions onto the user
Developers cannot do anything with it. User can decide if wanted to log in or just open a shell. Both of them are available.
Quote:
Originally Posted by MadMaverick9
Konsole does not have a simple checkbox to choose if you want to start the shell as a login shell or not.
And Konsole does not have a lot of other checkboxes as well to choose from, but you can enter any command with your preferred options if you wish.
So today was a day of reckoning. I finally grew sufficiently weary of being reminded by every shell prompt in Xfce Terminal or Konsole that I was running bash-5.1 to actually do something about it. So after a bit of fumbling about and relearning for the nth time the difference between .bash_profile and .bashrc, I got the perfectly cromulent bash prompt that I already had in the console by default.
What did I do in .bashrc? I assigned a value to PS1 and exported that assignment:
#!/bin/bash
export PS1='\u@\h:\w\$ '
Issue solved. But why did I have this issue?
PS1 gets defined and exported in /etc/profile. That definition endures all the trials and tribulations of console life, but when I run startx (runlevel 3 rules!) PS1 gets crushed. Why the PS1 hate in the gui? Is this some kind of anti-terminal bias? Why has my terminal emulator been having to deal with a hostile work environment? This terminal emulator is now safe. Going forward, PS1 is always going to be there. But what about all the other terminal emulators out there? Why does PS1 get unset?
When you run 'startx', it runs ~/.xinitrc that ends with a stanza like:
After looking at 'man bash' I think I have finally got this into my head regarding the 'startx' shell script..
From under the COMMAND EXECUTION heading:
Quote:
If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child.
Despite PS1 being marked for export in the login shell, that does not carry through to the subshell. Bash assumes that PS1 is only useful in an interactive shell so the PS1 variable setting needs to be defined in ~/.bashrc.
After looking at 'man bash' I think I have finally got this into my head regarding the 'startx' shell script..
From under the COMMAND EXECUTION heading:
Despite PS1 being marked for export in the login shell, that does not carry through to the subshell. Bash assumes that PS1 is only useful in an interactive shell so the PS1 variable setting needs to be defined in ~/.bashrc.
Not really [but almost]. It looks like a non-interactive bash will remove PS1 and an interactive shell will set a default and you can override it in .bashrc (if you wish). But there is no way to inherit it (as an exported variable).
Code:
# with empty ~/.bashrc
$ bash -i -c 'echo $PS1'
${debian_chroot:+($debian_chroot)}\u@\h:\w\$ # default, see man page
$ bash -c 'echo $PS1'
(empty, nothing)
# with real ~/.bashrc
$ bash -i -c 'echo $PS1'
(real prompt specified in bashrc)
$ bash -c 'echo $PS1'
(empty, nothing)
# env is /usr/bin/env, an "external tool" and PS1 is not exported
$ bash -c env | grep PS1 # empty
$ bash -c -i env | grep PS1 # empty
# set is built-in
$ bash -i -c set | grep PS1
PS1=<set by .bashrc>
$ bash -c set | grep PS1
(empty, nothing)
you can try it with and/or without export PS1, the result will be the same.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.