LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-25-2021, 12:16 AM   #16
MadMaverick9
Member
 
Registered: Aug 2010
Posts: 353
Blog Entries: 4

Rep: Reputation: Disabled

Quote:
Originally Posted by GazL
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"
 
1 members found this post helpful.
Old 09-25-2021, 02:39 AM   #17
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
Quote:
Originally Posted by MadMaverick9 View Post
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.

Last edited by GazL; 09-25-2021 at 02:45 AM.
 
Old 09-25-2021, 03:26 AM   #18
pghvlaans
Member
 
Registered: Jan 2021
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447

Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
Quote:
Originally Posted by GazL View Post
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
 
1 members found this post helpful.
Old 09-25-2021, 03:55 AM   #19
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
Here's a far better example.

Suppose I need to run a terminal under a specific locale other than what I normally use, so I:
LANG=some_locale.utf8 xterm &

Now, if xterm by default launched a login shell, $LANG would be overwritten to whatever is in /etc/profile.d/lang.sh.

This one is something I have actually needed to do from time to time, so it's not just theoretical.
 
Old 09-25-2021, 10:45 PM   #20
MadMaverick9
Member
 
Registered: Aug 2010
Posts: 353
Blog Entries: 4

Rep: Reputation: Disabled
@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.

Xfce Terminal does have a simple checkbox to make that choice:
docs.xfce.org/apps/xfce4-terminal/preferences/
docs.xfce.org/_media/apps/xfce4-terminal/terminal_prefs.png
 
2 members found this post helpful.
Old 09-26-2021, 12:50 AM   #21
emmet
Member
 
Registered: Oct 2003
Location: FL
Distribution: Slackware
Posts: 49

Original Poster
Rep: Reputation: 43
Quote:
Originally Posted by MadMaverick9 View Post
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.
 
2 members found this post helpful.
Old 09-26-2021, 01:01 AM   #22
pghvlaans
Member
 
Registered: Jan 2021
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 447

Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
Quote:
Originally Posted by MadMaverick9 View Post
@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.
Ah, sure. Thanks for clearing that up!
 
Old 09-26-2021, 07:04 AM   #23
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
Quote:
Originally Posted by MadMaverick9 View Post
@GazL:
Code:
LANG=some_locale.utf8 xterm +ls &


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.
 
Old 09-27-2021, 01:06 AM   #24
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 21,691

Rep: Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274
Quote:
Originally Posted by MadMaverick9 View Post

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 View Post
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 View Post
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.
Quote:
Originally Posted by MadMaverick9 View Post
That I have a problem with.
I can't see any problem here

Last edited by pan64; 09-27-2021 at 01:14 AM.
 
Old 09-27-2021, 03:35 AM   #25
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware64-15.0
Posts: 6,357

Rep: Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739
Quote:
Originally Posted by emmet View Post
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:
Code:
exec ck-launch-session dbus-launch --exit-with-session /usr/bin/startwmaker $NOCPP
The 'exec' is what removes the PS1 and PS2 environment variables.

You can see this by running bash -c 'exec env' before running 'startx'.
 
Old 09-27-2021, 05:00 AM   #26
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 21,691

Rep: Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274
Quote:
Originally Posted by allend View Post
When you run 'startx', it runs ~/.xinitrc that ends with a stanza like:
Code:
exec ck-launch-session dbus-launch --exit-with-session /usr/bin/startwmaker $NOCPP
The 'exec' is what removes the PS1 and PS2 environment variables.

You can see this by running bash -c 'exec env' before running 'startx'.
exec clears the environment only when -c is specified. And actually any program can alter its own environment and pass that to the children.
 
1 members found this post helpful.
Old 09-27-2021, 06:29 AM   #27
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
With or without -c exec does nothing to the process' environment. If something is dropping the env variable, then it's something else.

Anyway, exporting is not the way to go, it will cause breakage if used by an incompatible shell (e.g. attempting to use a bash specific PS1 in ksh)
 
1 members found this post helpful.
Old 09-27-2021, 07:39 AM   #28
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware64-15.0
Posts: 6,357

Rep: Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739
Thanks for pointing out my mistake.

I stand corrected.
 
Old 09-27-2021, 10:16 AM   #29
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware64-15.0
Posts: 6,357

Rep: Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739
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.
 
1 members found this post helpful.
Old 09-28-2021, 01:06 AM   #30
pan64
LQ Addict
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 21,691

Rep: Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274Reputation: 7274
Quote:
Originally Posted by allend View Post
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.
 
2 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Why does Debian host decide to ignore PS1 variable? Daws Linux From Scratch 3 04-10-2018 06:55 PM
[SOLVED] PS1: not working in .sh files, and why use 'export'? bashMe Linux - Newbie 9 11-28-2012 11:07 AM
zsh PS1, dollar sign in the beginning, why? Mr. Alex Linux - Newbie 1 01-25-2011 09:48 AM
set/unset programs to run at startup bubazoo Debian 2 04-16-2007 04:50 PM
Why doesn't the script change PS1? (RedHat) ForumJoiner Linux - Newbie 3 12-01-2006 03:59 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:05 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration