Bug 102825 - tcsh(1) sources /etc/profile.d/*.csh from the wrong file
Summary: tcsh(1) sources /etc/profile.d/*.csh from the wrong file
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: tcsh (Show other bugs)
(Show other bugs)
Version: beta1
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Bill Huang
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-21 15:49 UTC by KELEMEN Péter
Modified: 2007-04-18 16:57 UTC (History)
3 users (show)

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: ---


Attachments (Terms of Use)

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?


Note You need to log in before you can comment on or make changes to this bug.