The application of the ${FILESDIR}/bashrc-r1 file as /etc/bash/bashrc has inadvertently revealed a curious user-driven anti-pattern, which as follows. 1. user decides to 'customise' ~/.bashrc for the root user 2. user finds that there is no /root/.bashrc file 3. user deems it appropriate to run cp /etc/bash/bashrc ~/.bashrc The third step there might seem like a rational action to anyone not well versed in the particulars of bash invocation and initialisation. Unfortunately, it is deeply misguided (for obvious reasons). Instead, what they should have done is copy the /etc/skel/.bashrc file to /root, but the chances of such a user knowing this are slim to none. See, in particular, the confused exchanges with cfgauss and sunox in the following thread. https://forums.gentoo.org/viewtopic-t-1169020.html One obvious way in which this situation can be rendered less likely to occur is to put a comment in /etc/bash/bashrc indicating that it is not intended as a template for ~/.bashrc and noting the existing of /etc/skel/.bashrc instead. That much would be easy enough. Beyond that, I would note that it is questionable for the /root directory in the stage3 tarballs to lack the bash skeleton files. Could anything be done about it, I wonder? One of the problems with /etc/skel is that its contents depend on the packages that are installed. However, it is bash that is the principle concern here. Perhaps special provisions could be made for ensuring that the tarballs provide a /root directory containing the skeleton files that belong to bash at the time. That would further reduce the likelihood that a user decides that copying random files from /etc into place is an appropriate course of action.
s/principle/principal/
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68c208ecd6b805ebc7796d2b71ceef4614179a2d commit 68c208ecd6b805ebc7796d2b71ceef4614179a2d Author: Kerin Millar <kfm@plushkava.net> AuthorDate: 2024-06-19 08:00:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-20 17:53:44 +0000 app-shells/bash: uncouple 10-gentoo-color.bash; warn of bad .bashrc Some users choose to manage /etc/bash/bashrc directly and disregard any of its updates outright. Additionally, some users have ~/.bashrc as a copy of ${FILESDIR}/bashrc which is either exact or which contains only trivial modifications, meaning that the bashrc.d drop-ins end up being sourced twice. For both of these scenarios, users will presently encounter a diagnostic message indicating that the genfun_has_readline function does not exist. In turn, that is because the function is declared by /etc/bash/bashrc, while also being used by /etc/bash/bashrc.d/10-gentoo-color.bash. Since there is no particular need for 10-gentoo-color.bash to be coupled in this manner, jettison the function. Instead, have bashrc consider the exit status of the "shopt -s no_empty_cmd_completion" command and have 10-gentoo-color.bash perform its own test. Additionally, implement a new bashrc.d drop-in named "15-gentoo-bashrc-check.bash". Its purpose is to check whether ~/.bashrc exists as a copy of ${FILESDIR}/bashrc and instruct the user as to how to remedy the situation. After performing the check, it touches a file under ${TMPDIR} so that it can subsequently avoid driving the user mad. I recommend that this drop-in be removed one year hence. I disliked having to do this but consider it to be in the public interest. Signed-off-by: Kerin Millar <kfm@plushkava.net> Bug: https://bugs.gentoo.org/934523 Signed-off-by: Sam James <sam@gentoo.org> ...-5.1_p16-r11.ebuild => bash-5.1_p16-r12.ebuild} | 3 +++ ...sh-5.2_p26-r4.ebuild => bash-5.2_p26-r5.ebuild} | 3 +++ ....3_alpha-r3.ebuild => bash-5.3_alpha-r4.ebuild} | 3 +++ app-shells/bash/files/bashrc-r1 | 17 +++++++-------- .../bash/files/bashrc.d/10-gentoo-color.bash | 3 ++- .../files/bashrc.d/15-gentoo-bashrc-check.bash | 24 ++++++++++++++++++++++ 6 files changed, 42 insertions(+), 11 deletions(-)
