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

[jesnow]

Hi folks.

My system has worked just fine for a long long time, but its behavior just changed. Sure I can "just fix it" but it seems like there might be an unintended effect of something that changed in gentoo.

I am used to setting system aliases that affect every interactive shell in the system. Things like "alias dir = ls -al". These go into a drop-in file in /etc/profile.d/ since it's something I changed for my system.

But now since my most recent update, the dropins in /etc/profile.d are run but then overwritten with other aliases sourced in the directory /etc/bashrc.d/

So, I question the wisdom of turning every single config file into a directory. But there's nothing I can do about it, that's just modern life. I guess it's better than the windows registry or whatever voodoo they do in macos. At least these are human readable files. But I really miss easily remembered and consistent text files that configure your system.

But so I should be able to "source /etc/profile" and reasonably expect that the aliases in the dropin directory /etc/profile.d/ are executed and not stepped on. But that's not what happens.

Instead, the alias commands in /etc/bashrc.d/ are executed, as if /etc/profile.d/ didn't exist.

So the result is not at all what I want:

[jesnow]

To be clear: I know how to "git 'er done" as they say in Texas, but I would like the result to be correct. I'm clearly missing something.

[pjp]

When did you notice the change?

I thought there was a related news item, but I'm not seeing it. Maybe it could be related to a change intorduced by RumpletonBongworth where some issues are discussed in this post (and in other posts in that thread and possibly in other threads):

https://forums.gentoo.org/viewtopic-p-8830535.html#8830535

Of course it might not be related to that.

The part that tries to keep the old alias an only appending color seems like a major oops. By the declaration in the loop, _ is only the command, not what it may have been aliased to.
_________________
Quis separabit? Quo animo?

[jesnow]

Thanks!

I only noticed it yesterday, and the files in /etc/bashrc.d/ all have yesterday's filedate. So it sounds like it's related as you say to the introduction of bashrc scripts to include the no-readline functionality, I have no idea about that. I am running a very trailing-edge system in order not to have this exact kind of issue.

I'm going to let my emerge -DNua @world finish before I think about it any more. It hasn't even started on chromium or rust yet, so it could be a while.

Any further insight gratefully accepted.

Cheers,
Jon

[Hu]

As I understand it, /etc/profile.d is only evaluated by login shells. /etc/bash/bashrc.d is evaluated by both login and non-login interactive shells. Therefore:

[jesnow]

OK, now I'm doubly confused. Why is it not the intention to preserve aliases I set systemwide in /etc/profile.d?
Why even have /etc/profile.d if it is simply overridden?

Cheers,
Jon.

[Hu]

I don't know why bashrc.d forcibly sets those aliases. Perhaps the author expected no one would have set those aliases in profile.d, and so did not include a check whether they were defined.

As I said above, this is not being overridden because it's in profile.d. It's being overridden because profile.d runs first, and bashrc.d has no explicit check to avoid overriding things that were already done. If you had put something in profile.d that the bashrc.d fragment never touched, then your setting would not be overridden. I think you would have the same problem if you defined these in a bashrc.d that is evaluated earlier than the Gentoo bashrc.d fragment. This also suggests a solution: define these in bashrc.d, and in a file which sorts later than the Gentoo bashrc.d fragment. This solves two problems:

• First, by evaluating yours later, you overwrite Gentoo, rather than the other way around.
• Second, by defining yours in bashrc.d, they actually do apply to all interactive bash uses. Your current setup only affects login shells.

[mv]

Code with bashisms (like "alias") does not belong to /etc/profile.d anyway as it would break other shells which also source this directory at startup. Moreover, IIRC, alias works only in interactive shells (which a startup shell in general is not).

[pjp]

Alias isn't exclusive to bash, but your point still stands.


Interestingly, 'man bash' has no mention of /etc/bash (only /etc/bash_completion.d/). Section "Invocation" only mention /etc/profile and dot files in a user's home directory. Nor does app-shells/bash have any USE flags indicating the Gentoo files can be turned off. I'm guessing it is customary for distributions to provide such convenience enhancements.

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.
_________________
Quis separabit? Quo animo?

[mv]

[Zucca]

[eschwartz]

[pjp]

And that's a very good reason, and given how config files work in general, I have no better solution.

I like some color, but often the degree to which it can make something unreadable is astonishing. For example I just used less on 10-gentoo-color.bash and it was hard enough to read what the variable "NO_COLOR" was, so I had to cat the file to less. Which leads me to the point I was making above. That script checks to see if NO_COLOR is set. So the script needs to run to see that it doesn't need to run. And if the script was removed and someone decided they wanted to enable color, then they'd have to figure out how to get / re-enable the script.

For me at least the underlying problem is that color doesn't have (or I'm not aware of) a way to manage it effectively. Especially for remote shells where less color is available.
_________________
Quis separabit? Quo animo?

[Zucca]

[Hu]

You could do that, but then any subsequent updates you want to know about would be hidden. Overriding them in the live filesystem and watching for dispatch-conf to warn of changes is the safer option.

[Zucca]

[pjp]

But if you simply delete the file, then it gets reinstalled. If you leave a file with a one line comment "# Empty to prevent reinstall" then you still have to get red of the .cfg files that return.

The first alternatives that come to mind would be an rc-config like enable / disable, or a scripts.enable/disable file (similar to the various allow / deny files that are or were under /etc).
_________________
Quis separabit? Quo animo?

[Hu]

The options are:

• Edit the file to remove the undesirable behavior, possibly replacing the entire file with a one-line comment. Advantage: you get notified if a future change tries to modify this file, and you can decide whether the updated version still deserves to be disabled on this system. Disadvantage: you must deal with the notification even when the update is one you will ultimately decide to reject.
• Delete the file. I am unsure whether it is automatically restored as pjp says, but assuming it is, you may have a worse trade-off than above, depending on whether Portage silently restores the file or whether it writes a ._cfg_ and wants you to make the replacement live.
• Use INSTALL_MASK to inhibit installing the file. As a result, Portage never writes the ._cfg_ file, which could be seen as an advantage if you have decided you will always reject updates.

I don't want to prejudge the value of updates that have not been written yet, so I want to see that an update is proposed and make a decision when that happens. Therefore, in my opinion, the best option is one that instructs Portage to notify me of future updates. For an administrator who has decided to summarily reject all future updates, INSTALL_MASK is probably a better choice.

[flexibeast]

[pjp]

[jesnow]

[Zucca]

[RumpletonBongworth]

[RumpletonBongworth]

[flexibeast]