I'm trying to add a few directories to PATH in F35. I'm embarrassed to admit it isn't going well.
Where is PATH stored in F35 ?
When exactly does .bash_profile get executed ?
How does one get the bash environment reloaded without logging out and logging in ? $source <something> ? $exec bash ? ./bash ?
What gets executed upon logging out and logging back in, versus opening a new terminal (with Konsole) ?
$env should include everything in .bash_profile, right ?
Why doesn't F35 have ~/.profile or ~/.bashrc and instead has ~/.bash_profile ? Does .bash_profile replace .bashrc and .profile ? Would bash read .profile if I created one ? If so, when ?
What happened to .inputrc ?
Thanks
On 11Jan2022 14:15, linux guy linuxguy123@gmail.com wrote:
I'm trying to add a few directories to PATH in F35. I'm embarrassed to admit it isn't going well.
Where is PATH stored in F35 ?
In your processes' memory. Unhelpful. But it is _initialised_ by your login sequence. Yes, being pedantic here.
When exactly does .bash_profile get executed ?
1: Is your shell bash? (My interactive shell is zsh, by contrast.) Echoing $SHELL should confirm bash for you, or looking in /etc/passwd.
2: .bash_profile (or .profile, if the former is missing) gets run by _login_ shells.
On a text based terminal (eg the Linux console without a GUI), your login runs a login shell.
In a GUI such as a desktop the situation is more complicated:
- the GUI startup does not automatically run a login shell (to some extend because interaction or mistakes can then easily break the GUI startup).
- when you start a terminal it may or may not run a login shell; this can be controlled with the settings for your terminal emulator. What are you using?
Shells usually have a login and nonlogin startup mode - for bash this loosely means a login shell sources the .bash_profile (or.profile) on startup, and nonlogin interactive shells source the .bashrc. The specifics vary for other shells (eg zsh) but the idea's the same. The exact process for bash is explained in tedious details in "man bash".
The basic idea is/was that you'd put expensive stuff which only needed to happen once in the .bash_profile (setting $PATH, consulting some summary information, etc) and interactive-useful stuff in your .bashrc (setting interaction modes like command line editing, defining aliases, etc).
These days you can often get away with making every new terminal run a login shell. Look into that setting first up - it is the easiest fix.
I discourage you from polluting your .bashrc with complexity. Though a lot of distros prepollute it for you (have a look at /etc/bashrc, often a nightmare of complexity).
Personally, I keep my environment setting stuff in a distinct script, which I source from my .profile. Here's my .profile:
#!/bin/sh umask 002 [ -f $HOME/rc-local/profile ] && . $HOME/rc-local/profile : ${SHDIR:=$HOME/rc/shell} . $SHDIR/rigenv LUSER=$USER; export LUSER . $HOME/rc/shell/rc
Setting $PATH (and a billion other things) is done in the "rigenv" script mentioned above.
How does one get the bash environment reloaded without logging out and logging in ? $source <something> ? $exec bash ? ./bash ?
If your terminals run login shells, opening a new terminal will do. For that terminal, of course.
Or you can source your .profile (or separate script):
. ~/.bash_profile
$env should include everything in .bash_profile, right ?
"env" shows the exported environment - that which is inherited by subprocesses. Example:
foo=bah PATH=$HOME/bin:$PATH:/usr/local/bin export PATH
$PATH gets exports, $foo does not, so env will show $PATH and not $foo. But your local shell has $foo for whatever purpose.
Note that _inherited_ variables are automatically reexported. Because if this, good practice is to only export $UPPERCASE names, and to use $lowercase names for unexprted variables. This is because only discipline controls the use of this namespace. besides, it also makes it obvious which variables you expect to be local and which exported.
Why doesn't F35 have ~/.profile or ~/.bashrc and instead has ~/.bash_profile ? Does .bash_profile replace .bashrc and .profile ? Would bash read .profile if I created one ? If so, when ?
See "man bash". Bash uses .bash_profile for logins and .bashrc for nonlogin interactive shells.
What happened to .inputrc ?
The .inputrc is for controlling the readline library (used for interaction in bash and various other things). Maybe the defaults are considered nice enough - you can always add your own. Here's mine:
set editing-mode emacs set blink-matching-paren on set completion-ignore-case on set completion-query-items 1024 set disable-completion off set expand-tilde on set horizontal-scroll-mode off set mark-directories on set mark-symlinked-directories on set match-hidden-files off set page-completions on set print-completions-horizontally off set show-all-if-ambiguous on set visible-stats on Control-w:backward-kill-word
Cheers, Cameron Simpson cs@cskk.id.au
Comments below. Thanks for such a comprehensive answer.
On Tue, Jan 11, 2022 at 3:13 PM Cameron Simpson cs@cskk.id.au wrote:
On 11Jan2022 14:15, linux guy linuxguy123@gmail.com wrote:
I'm trying to add a few directories to PATH in F35. I'm embarrassed to admit it isn't going well.
Where is PATH stored in F35 ?
In your processes' memory. Unhelpful. But it is _initialised_ by your login sequence. Yes, being pedantic here.
Ha.
When exactly does .bash_profile get executed ?
1: Is your shell bash? (My interactive shell is zsh, by contrast.) Echoing $SHELL should confirm bash for you, or looking in /etc/passwd.
Yes, bash.
2: .bash_profile (or .profile, if the former is missing) gets run by _login_ shells.
Good to know.
On a text based terminal (eg the Linux console without a GUI), your
login runs a login shell.
In a GUI such as a desktop the situation is more complicated:
- the GUI startup does not automatically run a login shell (to some extend because interaction or mistakes can then easily break the GUI startup).
Interesting.
- when you start a terminal it may or may not run a login shell; this
can be controlled with the settings for your terminal emulator. What are you using?
Konsole. According to its settings, it runs /bin/bash when it starts up.
Shells usually have a login and nonlogin startup mode - for bash this
loosely means a login shell sources the .bash_profile (or.profile) on startup, and nonlogin interactive shells source the .bashrc.
OK, so there is my issue. ~/ does not have a .bashrc. I has .bash_profile only.
The specifics vary for other shells (eg zsh) but the idea's the same. The exact process for bash is explained in tedious details in "man bash".
RTFM ! RTFMP ! OK.
The basic idea is/was that you'd put expensive stuff which only needed to happen once in the .bash_profile (setting $PATH, consulting some summary information, etc) and interactive-useful stuff in your .bashrc (setting interaction modes like command line editing, defining aliases, etc).
Makes sense.
These days you can often get away with making every new terminal run a login shell. Look into that setting first up - it is the easiest fix.
Doesn't appear to be editable in Konsole, though maybe I could specify it as a parameter to /bin/bash that gets executed at startup. Haven't tried that yet.
I discourage you from polluting your .bashrc with complexity. Though a lot of distros prepollute it for you (have a look at /etc/bashrc, often a nightmare of complexity).
Mine is pretty clean.
Personally, I keep my environment setting stuff in a distinct script, which I source from my .profile. Here's my .profile:
#!/bin/sh umask 002 [ -f $HOME/rc-local/profile ] && . $HOME/rc-local/profile : ${SHDIR:=$HOME/rc/shell} . $SHDIR/rigenv LUSER=$USER; export LUSER . $HOME/rc/shell/rcSetting $PATH (and a billion other things) is done in the "rigenv" script mentioned above.
OK.
Here is my .bashrc:
######################################################################### # .bashrc
# Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi
# User specific environment if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]] then PATH="$HOME/.local/bin:$HOME/bin:$PATH" fi export PATH
# Uncomment the following line if you don't like systemctl's auto-paging feature: # export SYSTEMD_PAGER=
# User specific aliases and functions if [ -d ~/.bashrc.d ]; then for rc in ~/.bashrc.d/*; do if [ -f "$rc" ]; then . "$rc" fi done fi
unset rc
#####################################################################################################
Here is my .bash_profile:
####################################################################################
# .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs # empty right now.
#####################################################################################################
How does one get the bash environment reloaded without logging out and logging in ? $source <something> ? $exec bash ? ./bash ?
If your terminals run login shells, opening a new terminal will do. For that terminal, of course.
Or you can source your .profile (or separate script):
. ~/.bash_profile
Right. This doesn't seem to be working for me.
$env should include everything in .bash_profile, right ?
"env" shows the exported environment - that which is inherited by subprocesses. Example:
foo=bah PATH=$HOME/bin:$PATH:/usr/local/bin export PATH$PATH gets exports, $foo does not, so env will show $PATH and not $foo. But your local shell has $foo for whatever purpose.
Right. I get that.
Note that _inherited_ variables are automatically reexported. Because if
this, good practice is to only export $UPPERCASE names, and to use $lowercase names for unexprted variables. This is because only discipline controls the use of this namespace. besides, it also makes it obvious which variables you expect to be local and which exported.
Good tip.
Why doesn't F35 have ~/.profile or ~/.bashrc and instead has ~/.bash_profile ? Does .bash_profile replace .bashrc and .profile ?
Would
bash read .profile if I created one ? If so, when ?
See "man bash". Bash uses .bash_profile for logins and .bashrc for nonlogin interactive shells.
OK, this makes sense.
What happened to .inputrc ?
The .inputrc is for controlling the readline library (used for interaction in bash and various other things). Maybe the defaults are considered nice enough - you can always add your own. Here's mine:
set editing-mode emacs set blink-matching-paren on set completion-ignore-case on set completion-query-items 1024 set disable-completion off set expand-tilde on set horizontal-scroll-mode off set mark-directories on set mark-symlinked-directories on set match-hidden-files off set page-completions on set print-completions-horizontally off set show-all-if-ambiguous on set visible-stats on Control-w:backward-kill-word
Thanks for the detailed answer.
On 11Jan2022 15:32, linux guy linuxguy123@gmail.com wrote:
Comments below. Thanks for such a comprehensive answer.
- when you start a terminal it may or may not run a login shell; this
can be controlled with the settings for your terminal emulator. What are you using?
Konsole. According to its settings, it runs /bin/bash when it starts up.
If that setting is a command string, try changing it to:
/bin/bash --login
OK, so there is my issue. ~/ does not have a .bashrc. I has .bash_profile only.
I would put env settings in .bash_profile myself.
These days you can often get away with making every new terminal run a login shell. Look into that setting first up - it is the easiest fix.
Doesn't appear to be editable in Konsole, though maybe I could specify it as a parameter to /bin/bash that gets executed at startup. Haven't tried that yet.
See above.
Here is my .bashrc:
Thought you didn't have one of these?
######################################################################### # .bashrc
[... stock presupplied .bashrc, seems reasonable ...]
Here is my .bash_profile:
# .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
This is because bash runs the .bash_profile xor .bashrc (login vs interactive, not both). So having your .bash_profile source .bashrc is usually sensible. I do that last, at the bottom. Given that .bashrc is for the "interactive" stuff I test $- (the shell mode options). My ~/rc/shell/rc mentioned earlier goes:
#!/bin/sh : ${SHDIR:=$HOME/rc/shell} case "$-" in *i*)▸ . "$SHDIR/rc.real" ;; esac
i.e. only both with all that stuff (and there's a _lot_ of stuff :-) for an interactive shell (has the "i" option).
If your terminals run login shells, opening a new terminal will do. For that terminal, of course.
Or you can source your .profile (or separate script):
. ~/.bash_profileRight. This doesn't seem to be working for me.
Odd. Try this:
set -x; . ~/.bash_profile; set +x
should show what's happening, or not happening.
Cheers, Cameron Simpson cs@cskk.id.au
On Jan 11, 2022, at 17:14, Cameron Simpson cs@cskk.id.au wrote:
In a GUI such as a desktop the situation is more complicated:
- the GUI startup does not automatically run a login shell (to some
extend because interaction or mistakes can then easily break the GUI startup).
It’s actually a lot more complicated.
On modern Fedora systems (with GNOME, at least, not sure about KDE), the graphical processes are launched by systemd —user, which is forked off from systemd, and not your login shell.
This means that no login shell is involved at all when it comes to your graphical environment. If you want to inject an environment variable into the graphical environment, you can’t put it in your shell’s dotfiles, you have to use systemctl or have it defined in your PAM stack (the one for systemd —user, not the login shell).
So, since your Konsole is a child process of the GUI, and not a login shell, it never ran .bash_profile.
<rant>
This has been a pain for me because I’m used to variables being set in the login PAM stack, such as the randomized named Kerberos CCache being available to the GUI. Whoops, can’t read my kerberized NFS homedir! Can’t use Kerberos services in a graphical terminal! And their answer is to break several decades of standard behavior with credential caches and just use a cache assigned to the user instead of per-session. It is even worse if you need to use something that uses PAGs like OpenAFS.
</rant>
-- Jonathan Billings
Cameron Simpson writes:
How does one get the bash environment reloaded without logging out and logging in ? $source <something> ? $exec bash ? ./bash ?
If your terminals run login shells, opening a new terminal will do. For that terminal, of course.
Or you can source your .profile (or separate script):
. ~/.bash_profile
Be very careful with sourcing. These scripts are likely to set things in your environment or start processes that are appropriate at initialization, but will trash your current environment. For example, typically these scripts set PATH to a literal string. If you have added anything to PATH, you'll lose the additions. In other cases, they may add stuff or run stuff that you don't want done twice.
Running a new shell under the old one is always safe (since the old shell is still there when you exit this one), and if you need "login" behavior, "bash -l" gives you that.
Other than that, I'd give Cameron high marks for "Everything You Wanted to Know about Bash Initialization, But Were -- Rightly! -- Afraid to Ask". Good balance between what you should know if you're gonna mess with it and just plagiarizing the whole man page. :-)
On 12Jan2022 18:35, Stephen J. Turnbull stephen@xemacs.org wrote:
Running a new shell under the old one is always safe (since the old shell is still there when you exit this one), and if you need "login" behavior, "bash -l" gives you that.
+100 for this. Ashamed that I forgot to suggest it. Thanks, Cameron
On 12/01/2022 05:15, linux guy wrote:
I'm trying to add a few directories to PATH in F35. I'm embarrassed to admit it isn't going well.
Where is PATH stored in F35 ?
When exactly does .bash_profile get executed ?
How does one get the bash environment reloaded without logging out and logging in ? $source <something> ? $exec bash ? ./bash ?
What gets executed upon logging out and logging back in, versus opening a new terminal (with Konsole) ?
$env should include everything in .bash_profile, right ?
Why doesn't F35 have ~/.profile or ~/.bashrc and instead has ~/.bash_profile ? Does .bash_profile replace .bashrc and .profile ? Would bash read .profile if I created one ? If so, when ?
Read the man page for bash. It should answer many of your questions
What happened to .inputrc ?
It won't exist unless you create it.
-- Did 황준호 die?
On Tue, 11 Jan 2022 at 17:15, linux guy linuxguy123@gmail.com wrote:
I'm trying to add a few directories to PATH in F35. I'm embarrassed to admit it isn't going well.
Don't be embarrassed, Managing the PATH has problematic since UNIX was a teenager, as evidenced by the date in the following publication (allowing a few years to recognize the problem and develop a tool to manage it):
John L. Furlani, Modules: Providing a Flexible User Environment http://modules.sourceforge.net/docs/Modules-Paper.pdf, *Proceedings of the Fifth Large Installation * *Systems Administration Conference (LISA V)*, pp. 141-152, San Diego, CA, September 30 - October 3, 1991.
Current documentation: https://modules.readthedocs.io/en/latest/
Much of my "work/entertainment/community service" since I retired is helping users with various "mission-critical" large systems that rely on environment variables, including the PATH, to find executables, data, and (amazingly complex) configuration files. It is handy to be able to switch between the settings every Fedora install provides and the settings needed for a particular workflow.
-
Cameron Simpson -
Ed Greshko -
George N. White III -
Jonathan Billings -
linux guy -
Stephen J. Turnbull