Bug 102825

Summary: tcsh(1) sources /etc/profile.d/*.csh from the wrong file
Product: [Retired] Red Hat Linux Beta Reporter: KELEMEN Péter <peter.kelemen+rhbz>
Component: tcshAssignee: Miloslav Trmač <mitr>
Status: CLOSED NOTABUG QA Contact: Bill Huang <bhuang>
Severity: medium Docs Contact:
Priority: medium    
Version: beta1CC: notting, tao, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-17 23:15:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description KELEMEN Péter 2003-08-21 15:49:51 UTC
Description of problem:
csh(1) sources /etc/profile.d/*.csh from /etc/csh.cshrc, which is read by
every shell invoked.  profile.d contents should be sourced from /etc/csh.login
instead (i.e., only for login shells).  This would match current behaviour
of bash(1), since /etc/profile.d/*.sh is sourced from /etc/profile .

Version-Release number of selected component (if applicable):
tcsh-6.12-5

How reproducible:
Every time.

Comment 1 KELEMEN Péter 2004-08-17 23:15:47 UTC
Additional investigation turned up /etc/bashrc, which is not a standard
bash-related file, but sourced from /etc/skel/.bashrc, and therefore
from the individual user's ~/.bashrc.  There is indeed the snippet to
source /etc/profile.d/*.sh scripts in /etc/bashrc, so in a rather ugly
but existing way, profile.d parts get sourced for *every* shell
invocation.

NOTE to maintainer: bash 3.0 changes behaviour and sources
/etc/bash.bashrc for non-login interactive shells, so you can get rid
of this construct relying on user's .bashrc including the hook.

Thanks,
Peter


Comment 2 Miloslav Trmač 2004-08-18 08:07:28 UTC
Tim, comment #1 might interest you.

Comment 3 Tim Waugh 2004-08-18 08:15:36 UTC
I can't find any reference to /etc/bash.bashrc in the documentation or
the binary.

Comment 4 KELEMEN Péter 2004-08-18 08:24:13 UTC
chihiro:/tmp% wget -q http://ftp.gnu.org/gnu/bash/bash-3.0.tar.gz
chihiro:/tmp% md5sum bash-3.0.tar.gz
26c4d642e29b3533d8d754995bc277b3  bash-3.0.tar.gz
chihiro:/tmp% tar zxf bash-3.0.tar.gz
chihiro:/tmp% grep -r bash.bashrc bash-3.0
bash-3.0/config-top.h:/* #define SYS_BASHRC "/etc/bash.bashrc" */
chihiro:/tmp%

Comment 5 Tim Waugh 2004-08-18 08:26:50 UTC
(It's commented out)

Comment 6 Tim Waugh 2004-08-18 08:28:31 UTC
I think I must be missing the point -- how can we make use of this? 
Probably the /etc/bashrc owner should be cc'd.

Comment 7 KELEMEN Péter 2004-08-18 09:41:22 UTC
Yep, missed that.  Sorry.
I read the manual on a Debian system which has /etc/bash.bashrc support
enabled (filed appropriate bug to document this change in the Debian
man page).

However, the point is that it is there in the source for a reason,
even if it's uncommented.  I suggest using the opportunity to clean
up this mess by switching system-wide bashrc support in bash-3.0.
(And while you're at it, system wide bash_logout support as well.)
zsh(1) does it well for quite some time now.

Comment 8 Bill Nottingham 2004-08-18 15:49:02 UTC
Which parts specifically would you move, though?