Hi,
I have a question about the system startup files for bash.
The problem I had was that I set up an alias in ~/.bashrc, let's say alias ls="ls -lh" but it didn't work as "alias ls" reported alias ls='ls --color=auto'
What happens is that at the end ~/.bashrc sources /etc/bashrc which sources /etc/profile.d/*.sh that redefine "ll".
This happens on F24, F25, F26 and CentOS....
Easy to correct, but the question is: is that right? None of the examples I found on line does that and /etc/profile.d/*.sh are already sourced by /etc/profile (which is the first startup file read on login). Is this a quirk of RedHat or an error that still remains in the files or what?
GianPiero
On 25Oct2017 14:24, GianPiero Puccioni gianpiero.puccioni@isc.cnr.it wrote:
I have a question about the system startup files for bash.
The problem I had was that I set up an alias in ~/.bashrc, let's say alias ls="ls -lh" but it didn't work as "alias ls" reported alias ls='ls --color=auto'
What happens is that at the end ~/.bashrc sources /etc/bashrc which sources /etc/profile.d/*.sh that redefine "ll".
This happens on F24, F25, F26 and CentOS....
Easy to correct, but the question is: is that right? None of the examples I found on line does that and /etc/profile.d/*.sh are already sourced by /etc/profile (which is the first startup file read on login). Is this a quirk of RedHat or an error that still remains in the files or what?
There are at least 2 things wrong.
First, the .bashrc (which one presumes first came from the template in /etc/skel) should source /etc/bashrc _first_, not last.
Second, /etc/bashrc should _not_ be sourcing anything in /etc/profile.d. That is for _login_ shells.
Have a look at the "INVOCATION" section of "man bash".
Bash has roughly 3 modes: batch mode, interactive mode and login mode.
Batch mode is used to run scripts. It should basicly source nothing new.
An interactive shell should source your .bashrc, to get settings useful for interactive use (convenience aliases like your "ls", prompt settings, etc).
A login shell should source /etc/profile, to get per login fuller settings (set up your $PATH, and so forth, often more expensive than plain "interactive" shells). It is very common for this in turn to source your .bashrc as a final act if the shell is also interactive.
So the bashrc has _no_ business sourcing /etc/profile or /etc/profile.d.
In the modern world (GUI desktop) the picture is complicated and what you're observing is probably a consequence of bad decisions to address that complication.
In ancient times, one logged in on a serial terminal, or less anciently, on a text mode PC console. You started a single login shell, which ran /etc/profile once, setting up your environment. All subshells would be interactive, sourcing the .bashrc (or equivalent) for interactive settings like convenience aliases. You might then start X11 to get a GUI desktop, and reasonably all the terminal emulators you then run would just run plain interactive shells, since your /etc/profile had already happened.
With a GUI login, the desktop starts up and the terminals you might invoke don't have the benefit of an original sourcing of /etc/profile (unless you've made personal efforts to that end, as I do).
As a consequence, GUI desktop often start terminals with shells in "login" mode inside them, expressly to ensure that you get your /etc/profile and .profile sourced. Slower but gets it done. On a modern machine the performance issue is usually minor.
However, terminal emulators might not do that. So someone in bash install setup land for the various distros has taken it upon themselves to make ordinary interactive shells act like login shells. Gah! Overkill.
However, that is the kind of decision that leads to the bashrc sourcing /etc/profile stuff.
Hoping this explains the situation somewhat.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au)
On 25 October 2017 at 19:13, Cameron Simpson cs@cskk.id.au wrote:
On 25Oct2017 14:24, GianPiero Puccioni gianpiero.puccioni@isc.cnr.it wrote:
I have a question about the system startup files for bash.
The problem I had was that I set up an alias in ~/.bashrc, let's say alias ls="ls -lh" but it didn't work as "alias ls" reported alias ls='ls --color=auto'
What happens is that at the end ~/.bashrc sources /etc/bashrc which sources /etc/profile.d/*.sh that redefine "ll".
This happens on F24, F25, F26 and CentOS....
Easy to correct, but the question is: is that right? None of the examples I found on line does that and /etc/profile.d/*.sh are already sourced by /etc/profile (which is the first startup file read on login). Is this a quirk of RedHat or an error that still remains in the files or what?
There are at least 2 things wrong.
First, the .bashrc (which one presumes first came from the template in /etc/skel) should source /etc/bashrc _first_, not last.
The order in which things are done in ~/.bashrc is the responsibility of the person who makes changes to the default. Maybe /etc/skel/.bashrc should start with a paragraph explaining that user additions should be put below the "User specific" line.
Second, /etc/bashrc should _not_ be sourcing anything in /etc/profile.d.
That is for _login_ shells.
Have a look at the "INVOCATION" section of "man bash".
Bash has roughly 3 modes: batch mode, interactive mode and login mode.
Batch mode is used to run scripts. It should basicly source nothing new.
An interactive shell should source your .bashrc, to get settings useful for interactive use (convenience aliases like your "ls", prompt settings, etc).
A login shell should source /etc/profile, to get per login fuller settings (set up your $PATH, and so forth, often more expensive than plain "interactive" shells). It is very common for this in turn to source your .bashrc as a final act if the shell is also interactive.
So the bashrc has _no_ business sourcing /etc/profile or /etc/profile.d.
Ten years ago there was a discussion of whether this sourcing should be done only for non-login shells, so it is not a new thing, see: https://www.redhat.com/archives/nahant-list/2007-May/msg00235.html
In the modern world (GUI desktop) the picture is complicated and what you're observing is probably a consequence of bad decisions to address that complication.
In ancient times, one logged in on a serial terminal, or less anciently, on a text mode PC console. You started a single login shell, which ran /etc/profile once, setting up your environment. All subshells would be interactive, sourcing the .bashrc (or equivalent) for interactive settings like convenience aliases. You might then start X11 to get a GUI desktop, and reasonably all the terminal emulators you then run would just run plain interactive shells, since your /etc/profile had already happened.
With a GUI login, the desktop starts up and the terminals you might invoke don't have the benefit of an original sourcing of /etc/profile (unless you've made personal efforts to that end, as I do).
As a consequence, GUI desktop often start terminals with shells in "login" mode inside them, expressly to ensure that you get your /etc/profile and .profile sourced. Slower but gets it done. On a modern machine the performance issue is usually minor.
However, terminal emulators might not do that. So someone in bash install setup land for the various distros has taken it upon themselves to make ordinary interactive shells act like login shells. Gah! Overkill.
However, that is the kind of decision that leads to the bashrc sourcing /etc/profile stuff.
Hoping this explains the situation somewhat.
When there is a choice between having more things "just work" for pointy-clicky users who have never encountered a terminal at a cost of additional complexity for guru-class users who work with the shell, the "just work" option has advantages:
1. gurus spend less time sorting out problems with broken GUI apps for the pointy-clicky types
2. pointy-clicky types find fewer frustrations and may decide that linux can be useful
Allegedly, on or about 26 October 2017, George N. White III sent:
When there is a choice between having more things "just work" for pointy-clicky users who have never encountered a terminal at a cost of additional complexity for guru-class users who work with the shell, the "just work" option has advantages:
- gurus spend less time sorting out problems with broken GUI apps
for the pointy-clicky types
- pointy-clicky types find fewer frustrations and may decide that
linux can be useful
While that may be so, it is advantageous if they continue to do things, behind the scenes, in the traditional way.
* Less re-inventing of the wheel. * Less surprises when someone customises something following established instructions. * Settings for things stored in the same place, whether you work from the command line or a GUI...
Having said that, the whole BASH config file conglomeration does not look pretty to me.
Let's say that I want to make an alias that all users can use. I'm not sure where it goes, bashrc or profile.
less /etc/bashrc # /etc/bashrc # System wide functions and aliases # Environment stuff goes in /etc/profile
Okay, having read that, I'll go look at /etc/profile. It seems to suggest that aliases go in /etc/profile.
less /etc/profile
# /etc/profile # System wide environment and startup programs, for login setup # Functions and aliases go in /etc/bashrc
It seems to suggest that aliases go in /etc/bashrc.
There's some shockingly bad grammar in those opening descriptions. I can't really tell if the bashrc description is meant to say this file is for system wide functions and aliases, profile is for environment stuff. It looks like one long badly typed sentence. Programmers should write coherent sentences, and it'd help if they used normal punctuation.
On Wed, Oct 25, 2017 at 6:13 PM, Cameron Simpson cs@cskk.id.au wrote:
There are at least 2 things wrong.
First, the .bashrc (which one presumes first came from the template in /etc/skel) should source /etc/bashrc _first_, not last.
Second, /etc/bashrc should _not_ be sourcing anything in /etc/profile.d. That is for _login_ shells.
Fedora's been sourcing "/etc/profile.d/*.sh" for many years. IIRC, the rationale's that it equalizes login and interactive sessions.
On 28Oct2017 10:02, Tom H tomh0665@gmail.com wrote:
On Wed, Oct 25, 2017 at 6:13 PM, Cameron Simpson cs@cskk.id.au wrote:
There are at least 2 things wrong.
First, the .bashrc (which one presumes first came from the template in /etc/skel) should source /etc/bashrc _first_, not last.
Second, /etc/bashrc should _not_ be sourcing anything in /etc/profile.d. That is for _login_ shells.
Fedora's been sourcing "/etc/profile.d/*.sh" for many years. IIRC, the rationale's that it equalizes login and interactive sessions.
[ Specificly, ourcing this from the bashrc. ] Yeah I know. I loathe it. I understand the tradeoff there, and why it came about. Still unhappy.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au)
On 25 October 2017 at 09:24, GianPiero Puccioni < gianpiero.puccioni@isc.cnr.it> wrote:
Hi,
I have a question about the system startup files for bash.
The problem I had was that I set up an alias in ~/.bashrc, let's say alias ls="ls -lh" but it didn't work as "alias ls" reported alias ls='ls --color=auto'
What happens is that at the end ~/.bashrc sources /etc/bashrc which sources /etc/profile.d/*.sh that redefine "ll".
This happens on F24, F25, F26 and CentOS....
Easy to correct, but the question is: is that right? None of the examples I found on line does that and /etc/profile.d/*.sh are already sourced by /etc/profile (which is the first startup file read on login). Is this a quirk of RedHat or an error that still remains in the files or what?
On fedora 26 server, /etc/skel/.bashrc is:
# .bashrc
# Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi
# Uncomment the following line if you don't like systemctl's auto-paging feature: # export SYSTEMD_PAGER=
# User specific aliases and functions
I take the last line as a hint that users should add stuff to the end of the file. If I put alias ls="ls -lh" after the last line, it is respected in new shells.
On 26Oct2017 12:57, George N. White III gnwiii@gmail.com wrote:
On fedora 26 server, /etc/skel/.bashrc is:
# .bashrc
# Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi
# Uncomment the following line if you don't like systemctl's auto-paging feature: # export SYSTEMD_PAGER=
# User specific aliases and functions
I take the last line as a hint that users should add stuff to the end of the file. If I put alias ls="ls -lh" after the last line, it is respected in new shells.
The hint could be better. While it might seem obvious, saying the "User specific aliases and functions should go below this line" might be an improvement.
I'm presuming the OP put their stuff up the top.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au)
[Cameron Simpson]
The hint could be better. While it might seem obvious, saying the "User specific aliases and functions should go below this line" might be an improvement.
I'm presuming the OP put their stuff up the top.
Yes I did, but I realized that my .bashrc comes from a very old Fedora, as I reinstalled several versions on this machine, and that was the suggestion at time (I think).
My point was more about the fact that profile.d was sourced by both /etc/bashrc and /etc/profile and this didn't sound right.
GianPiero
-
Cameron Simpson -
George N. White III -
GianPiero Puccioni -
Tim -
Tom H