Gentoo Forums :: View topic - Primacy of /etc/bashrc.d vs /etc/profile.d

Primacy of /etc/bashrc.d vs /etc/profile.d

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2

Gentoo Forums Forum Index

Installing Gentoo

View previous topic :: View next topic

Author

Message

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Sun Sep 01, 2024 1:11 am Post subject: Re: Primacy of /etc/bashrc.d vs /etc/profile.d

jesnow wrote:

/etc/bash/bashrc.d/* are sourced *twice!*.
This is really not what should be happening.

Some users elect to copy /etc/bash/bashrc to ~/.bashrc, resulting in double-sourcing. Perhaps you are among them? There is now a check to warn users of this particular misconfiguration.

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Sun Sep 01, 2024 9:26 pm Post subject:

I have submitted a patch which, if accepted, will address the matter by refraining from defining an alias in the case that an alias or function already exists by the specified name.

mv
Watchman

Joined: 20 Apr 2005
Posts: 6780

Posted: Sun Sep 08, 2024 4:43 pm Post subject:

flexibeast wrote:

RumpletonBongworth wrote:

All implementations of the Shell Command Language must support alias.

Indeed. Here's POSIX on the matter.

Well, that's the brand new POSIX standard. Not sure whether it is already officially released or still a topic under discussion, but I am quite sure that it was not released before 2024.

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Sun Sep 08, 2024 5:48 pm Post subject:

mv wrote:

flexibeast wrote:

RumpletonBongworth wrote:

All implementations of the Shell Command Language must support alias.

Indeed. Here's POSIX on the matter.

Well, that's the brand new POSIX standard. Not sure whether it is already officially released or still a topic under discussion, but I am quite sure that it was not released before 2024.

The alias utility was introduced by the publication of X/Open Common Applications Environment (CAE) Portability Guide Issue 4, also known as XPG4. That was in 1992. It was subsumed by the Single UNIX Specification in 1994.

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 4109
Location: Rasi, Finland

Posted: Sun Sep 08, 2024 6:25 pm Post subject:

RumpletonBongworth wrote:

Afaik SUS is a superset of POSIX. Right?
Although 1994 is already 30 years ago. So I would guess the standard (alias) would have been included in POSIX by now then.
_________________
..: Zucca :..

My gentoo installs:

init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:

I am NaN! I am a man!

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Sun Sep 08, 2024 6:53 pm Post subject:

Zucca wrote:

RumpletonBongworth wrote:

Afaik SUS is a superset of POSIX. Right?
Although 1994 is already 30 years ago. So I would guess the standard (alias) would have been included in POSIX by now then.

Allow me to settle this once and for all.

alias was introduced in an official capacity by XPG4
XPG4 was assimilated by SUSv1
alias was therefore present in SUSv1
alias was therefore present in SUSv2
alias was therefore present in SUSv3, which is essentially the same as POSIX-1.2001
POSIX-1.2001 consolidated the POSIX.1, POSIX.2, and SUS standards through the efforts of the Austin Group

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 4109
Location: Rasi, Finland

Posted: Sun Sep 08, 2024 8:10 pm Post subject:

RumpletonBongworth wrote:

alias was therefore present in SUSv3, which is essentially the same as POSIX-1.2001
POSIX-1.2001 consolidated the POSIX.1, POSIX.2, and SUS standards through the efforts of the Austin Group

So based on these, alias was standardized into POSIX in 2001 (Or in beginning of 2002).
_________________
..: Zucca :..

My gentoo installs:

init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:

I am NaN! I am a man!

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Mon Sep 09, 2024 2:52 am Post subject:

Zucca wrote:

RumpletonBongworth wrote:

alias was therefore present in SUSv3, which is essentially the same as POSIX-1.2001
POSIX-1.2001 consolidated the POSIX.1, POSIX.2, and SUS standards through the efforts of the Austin Group

So based on these, alias was standardized into POSIX in 2001 (Or in beginning of 2002).

Yes. At that point, it became an element of Shell and Utilities, Issue 6 (XCU). There it has remained through all of the subsequent issues and so-called technical corrigenda.

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Fri May 02, 2025 6:54 am Post subject:

As of bash-5.2_p37-r1, the aliases shall no longer be defined in the case that they already exist as aliases and/or functions.

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 4109
Location: Rasi, Finland

Posted: Thu May 15, 2025 8:38 am Post subject:

So, overriding "system set" aliases on user's own profile cannot be done, unless prepended with unalias -command first.
_________________
..: Zucca :..

My gentoo installs:

init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:

I am NaN! I am a man!

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Thu May 15, 2025 3:17 pm Post subject:

Zucca wrote:

So, overriding "system set" aliases on user's own profile cannot be done, unless prepended with unalias -command first.

I do not understand this remark. The act of declaring an alias will always replace a prior alias by the same name. Let's assume that you declare an ls alias. If you:

declare it in ~/.bashrc, it will prevail
declare it in ~/.bash_profile, it will prevail (provided bash is a login shell)
declare it in ~/.profile, it will prevail (provided bash is a login shell and ~/.bash_profile does not exist)

This has always been the case. However, if you:

declare it in an /etc/profile.d/ drop-in, it shall not be replaced by 10-gentoo-color.bash

… which was not the case prior to 5.2_p37-r1.

EDIT: Should anything be unclear, you may trace the initialisation process. The command below simulates the launch of an interactive (-i) login (-l) shell. Note, however, that PS4 - if employed in its capacity as an environment variable - will only be honoured for non-root users.

Code:

PS4='+$BASH_SOURCE:$LINENO: ' bash -xilc '' |& less

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Fri May 16, 2025 1:09 am Post subject:

pjp wrote:

Having scripts do things then requiring users to create scripts to undo them seems an interesting mechanism. Although it may partially explain some of the performance of modern computing.

In re-reading this thread, I came across this portion of one of your posts and - though tangental to the topic of the thread - I would like to address it.

Firstly, sourcing a file isn't quite the same thing as executing a script. It entails the current shell opening a file and reading from it. While doing so can never be cost-free, it does forgo the expense of forking and executing a new shell. Consider whether you may be over-estimating how meaningfully expensive it is to do this in the common case, especially given that login/interactive shells tend to be spawned at an exceedingly low frequency.

Secondly, bash does not necessarily consume the entirety of the file before proceeding to execute its contents, as many other scripting languages do. Instead, it reads the file piecemeal and acts upon it as it goes along. However, it is obligated to read compound commands in their entirety so, for instance, the if/fi statement at the beginning of 10-gentoo-color.bash must be read in full before bash can execute the statement and have the option of returning (if, indeed, a return statement were to be present). As an aside, this is why it can be very dangerous to edit shell scripts while they are in the process of still running, and why compound commands may be employed as a defence against this pitfall.

Thirdly, it is not the case that 10-gentoo-color.bash serves no purpose in the case that NO_COLOR is non-empty, because it is still charged with defining the PS1 variable. Of course, that is not to say that the code could not be further micro-optimised. I can think of several ways to do so off-hand. However, I would also say that there is often a trade-off between code legibility and performance. On my part, I would have to be convinced that the effort is tangibly worthwhile. Which brings my neatly on to my final point.

Fourthly, it is quite straightforward to benchmark things in bash. With that in mind, let's get some figures. We'll set NO_COLOR and source the above-mentioned drop-in 50,000 times in a row.

Code:

# qlist -Ive bash
app-shells/bash-5.2_p37-r3
# cd /etc/bash/bashrc.d
# ( export NO_COLOR=1; time for ((i=0; i<50000; i++)); do . ./10-gentoo-color.bash; done )

real 0m7.981s
user 0m7.588s
sys 0m0.392s

That's on one of my Sandy Bridge based systems. Now, let's compare against another unit which simply sets PS1 up front and immediately returns if NO_COLOR is empty, using a very short compound command to do so (the conditional command). In the case that NO_COLOR is non-empty, it will proceed only to execute the builtin true command, which is inexpensive. In other words, I'm affording this test case a deliberately unfair advantage, on account of being very short and doing very little.

Code:

# printf %s\\n 'PS1="\u@\h \w \\\$ "' '[[ ! $NO_COLOR ]] || return 0' 'true' > sourceme
# ( export NO_COLOR=1; time for ((i=0; i<50000; i++)); do . ./sourceme; done )

real 0m1.507s
user 0m1.255s
sys 0m0.252s

Certainly, it is faster. But how much faster? Since 50,000 iterations occurred, we can surmise that it is faster by (7.981 - 1.507) / 50000 seconds, which is a whopping 0.00012948s in my case. Or, if you prefer, 0.12948ms; not much over a tenth of a millisecond. I'm not opposed to making things faster, but you can surely see why I might not consider it to be the utmost priority as far as this particular drop-in is concerned.

...

All that being said, I want to make it clear that I am largely sympathetic to the content of your posts and the concerns raised by them.

EDIT: After posting, I realised that I was using an experimental modification of 10-gentoo-color.bash. So I restored the stock version, as provided by bash-5.2_p37-r3. With that, 50000 iterations benchmarked at 0m6.644s of wall time. Therefore, my sourceme test case was faster by (6.644 - 1.507) / 50000 = 0.00010274s.

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 4109
Location: Rasi, Finland

Posted: Fri May 16, 2025 5:34 pm Post subject:

RumpletonBongworth wrote:

the aliases shall no longer be defined in the case that they already exist as aliases and/or functions.

... seem to contradict with ...

RumpletonBongworth wrote:

The act of declaring an alias will always replace a prior alias by the same name.

Or did you meant, Gentoo has now proper way of handling of aliases by fixing order in which the scripts are sourced?
_________________
..: Zucca :..

My gentoo installs:

init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:

I am NaN! I am a man!

Hu
Administrator

Joined: 06 Mar 2007
Posts: 23534

Posted: Fri May 16, 2025 6:07 pm Post subject:

As I read the difference between the files installed by the -r0 versus -r2 ebuilds, someone (possibly RumpletonBongworth) modified the profile.d file to work as RumpletonBongworth described:

Code:

@@ -48,19 +47,22 @@

if (( gentoo_color > 0 )); then
# Colorize the output of diff(1), grep(1) and a few coreutils utilities.
+ # However, do so only where no alias/function by the given name exists.
for _ in diff dir grep ls vdir; do
- alias "$_=$_ --color=auto"
+ if [[ $(type -t "$_") == file ]]; then
+ alias "$_=$_ --color=auto"
+ fi
done

So, the shell will do an overwrite if instructed, as the second quoted bit says, but the script deliberately avoids calling alias in the case that an alias or function has been defined (presumably, by the user), in the expectation that the existing definition is preferred over what this alias would do.

RumpletonBongworth
Tux's lil' helper

Joined: 17 Jun 2024
Posts: 108

Posted: Fri May 16, 2025 6:07 pm Post subject:

Zucca wrote:

RumpletonBongworth wrote:

the aliases shall no longer be defined in the case that they already exist as aliases and/or functions.

... seem to contradict with ...

RumpletonBongworth wrote:

The act of declaring an alias will always replace a prior alias by the same name.

Or did you meant, Gentoo has now proper way of handling of aliases by fixing order in which the scripts are sourced?

Effectively, "the aliases shall no longer be (re-)defined (by the system /etc/bash/bashrc, via /etc/bash/bashrc.d/10-gentoo-color.bash) in the case that they already exist as aliases/functions". The type builtin is used to make that assessment.

Code:

# unalias ls; unset -f ls
# type -t ls
file
# ls() { command ls --color=auto "$@"; }; type -t ls
function
# unset -f ls; alias ls='ls --color=auto'; type -t ls
alias

So, only if the output is "file" will /etc/bash/bashrc act as if it has the right to define an alias. Before I made that change, Gentoo's /etc/bash/bashrc had always acted as if it had the right to clobber any existing aliases without so much as a by-your-leave, on the condition that a colour terminal be detected.

This addresses jesnow's complaint by allowing a previously declared alias to retain its primacy. The obvious alternative would have been to define no 'system' aliases at all and let it be the responsibility of the user. You can probably imagine the sheer volume of complaints that would have arisen.

EDIT: Minor wording improvement.

Zucca
Moderator

Joined: 14 Jun 2007
Posts: 4109
Location: Rasi, Finland

Posted: Sat May 17, 2025 4:42 pm Post subject:

Thank you, both, for the explanations. :)
_________________
..: Zucca :..

My gentoo installs:

init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:

I am NaN! I am a man!

Display posts from previous:

	Gentoo Forums Forum Index Installing Gentoo	All times are GMT Goto page Previous 1, 2
Page 2 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2025 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy