Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63618 - [filesystem] /etc/profile - proposal of change

Attached to Project: Arch Linux
Opened by marcin82 (marcin82) - Sunday, 01 September 2019, 12:28 GMT
Last edited by Sébastien Luttringer (seblu) - Saturday, 02 May 2020, 10:25 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I have proposal to move "# Source global bash config" section before "# Load profiles from /etc/profile.d" to avoid overwriting PS1 variable **if someone wants to define/customize global shell preferences** in /etc/profile.d/*.sh instead of editing /etc/profile or /etc/bash.bashrc with future *.pacnew files handling.

For comparison:
- Debian, package: base-files, /etc/profile
- Fedora, package: setup, /etc/profile, as in Arch, but /etc/bash.bashrc sources once more all /etc/profile.d/*.sh files (redundant operation).
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Saturday, 02 May 2020, 10:25 GMT
Reason for closing:  Won't implement
Comment by Eli Schwartz (eschwartz) - Sunday, 01 September 2019, 14:58 GMT
But PS1 handling should be done in something specific to your shell anyway, because for example bashisms like PS1='[\u@\h \w]\$' won't work in some other POSIX-compatible shells.

What is the problem with treating /etc/bash.bashrc like the backup file it is, editing it directly, and merging your .pacnew in the quite uncommon cases it changes?

What is wrong with expecting users to customize their highly personal prompt in their own dotfiles?
Comment by marcin82 (marcin82) - Sunday, 01 September 2019, 17:28 GMT
> But PS1 handling should be done in something specific to your shell anyway, because for example bashisms like PS1='[\u@\h \w]\$' won't work in some other POSIX-compatible shells.

Does it mean, that PS1 of bash, underlying of "base" group with about ~70 files with shebang "#!/bin/bash" in standard desktop installation, shouldn't work too, being overwritten by /etc/bash.bashrc because of tricky syntax of /etc/profile? If /etc/zshrc would ever exist with PROMPT= definition, PROMPT in /etc/profile.d/* would be also overwritten...

> What is the problem with treating /etc/bash.bashrc like the backup file it is, editing it directly, and merging your .pacnew in the quite uncommon cases it changes?

Because maintaining of one file independently in /etc/profile.d/ is more comfortable that interfering with system standard config? What is wrong in it than one can have his own opinion and using /etc/profile.d to purposes it was created?

> What is wrong with expecting users to customize their highly personal prompt in their own dotfiles?

What is wrong with, even for two profiles, if I want to have some common settings, and PS1 various for user/root, defined (by if statement) in one central file instead of doubled lines in ~/.bashrc files?

You know what? I'm not here to judge. Judging is role for developers. My role is waiting for decision.
Comment by Sébastien Luttringer (seblu) - Saturday, 02 May 2020, 10:24 GMT
/etc/profile* files are executed by *login* bourne compatible shells, interactive or not.
While /etc/bash.bashrc is a bash only, Arch specific, resource file loaded when started interactive and non-login.

/etc/profile.d could definitively be used to avoid edition of /etc/profile.
But, putting bash global config (like PS1) into /etc/profile* is a bad idea.

We could image adding the same kind of include mechanism for global bashrc, and have /etc/bash.bashrc source /etc/bash.bashrc.d/*.
While I'm personally fan of .d configuration mechanism, this doesn't look like a popular request and, as Eli pointed, editing bash.bashrc is something expected.
Anyway, if this change is desirable, it should be made in bash package.

Loading...