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

--
George N. White III <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia