Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 128823 - /etc/bashrc needs to run /etc/profile.d/term.sh for ALL interactive shells
Summary: /etc/bashrc needs to run /etc/profile.d/term.sh for ALL interactive shells
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: setup
Version: 2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 122815
TreeView+ depends on / blocked
 
Reported: 2004-07-30 01:35 UTC by Eido Inoue
Modified: 2014-03-17 02:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-08-10 20:40:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Eido Inoue 2004-07-30 01:35:45 UTC
Description of problem:
FC2 /etc/bashrc will run the files in /etc/profile.d only if
interactive and it's the top level shell. /etc/bashrc needs to be
modified so that term.sh is run for any interactive shell, regardless
of level.

Version-Release number of selected component (if applicable):
2.5.33-1

Additional info:

RHEL3 will run /etc/profile.d/term.sh for any interactive shell-- no
changes are needed for that.

Comment 1 Hans de Goede 2004-07-30 06:31:09 UTC
When/where exactly does this go wrong? if a user starts a terminal the
shell started in this terminal is a toplevel shell, if a user starts
additonal shells in this terminal then TERM already has the correct
value, or am I missing something?



Comment 2 Eido Inoue 2004-07-30 20:14:03 UTC
misdiagnosis about the top level.

in FC2 and beyond, TERM is preset to "dumb", which causes the term.sh
script to ignore the guts of it.

in RHEL3, TERM is preset to "xterm".

Will make the appropriate changes to term.sh

Comment 3 Hans de Goede 2004-07-31 07:52:13 UTC
Hmm, then why does the current term.sh work on my FC3-test1 + rawhide
updates system?


Comment 4 Bill Nottingham 2004-08-10 20:40:43 UTC
Closing as notabug for now.

Comment 5 Kasper Dupont 2004-11-16 07:35:22 UTC
SHLVL does not tell you if the shell is a login shell. If you type
"bash -l" the SHLVL environment will be increased, and the new shell
will source the files from /etc/profile.d/ twice. There are probably
also ways to cause the SHLVL to be 1 even for a nonlogin shell.

The current configuration files looks like a mess. The last thing
/etc/profile does is to source files from /etc/profile.d, but after
that has happened ~/.bash_profile will source ~/.bashrc which again
will source /etc/bashrc which may source files from /etc/profile.d
again. Rather than processing files from /etc/profile.d twice and
trying to make the two locations agree on who is responsible, it
should be changed so they are sourced exactly once.

I can think of two possible ways to accomplish this. The first would
be to let ~/.bash_profile not source ~/.bashrc. And then change
/etc/bashrc such that it always sources files from /etc/profile.d. The
other approach would be to let /etc/profile never source files from
/etc/profile.d and always make it the responsibility of /etc/bashrc.

It also seems to me, that there should be a place for files that we
want sourced only in login shells. Currently it appears that files in
/etc/profile.d are intended to be sourced by every interactive shell.


Comment 6 Hans de Goede 2004-11-16 07:52:22 UTC
Only running profile.d scripts for a login shell is not an option, you
want to run them to for a shell started from xterm. Basicly you want
to run them once for every interactive shell.


Comment 7 Kasper Dupont 2004-11-16 08:51:20 UTC
Hans could you please elaborate on your last comment. Indeed the files
currently in profile.d are intended to be sourced once in every
interactive shell, and except from a few exceptions that is also what
happens. If a package had a file that was intended to be sourced only
in login shells, where would it put it?


Comment 8 Hans de Goede 2004-11-16 09:05:44 UTC
I was just trying to warn that when any changes are made that one
should be carefull that the files in profile.d don't end up only being
sourced for a login or only for a non login interactive shell.


Comment 9 Kasper Dupont 2004-11-23 20:22:17 UTC
I just found a case where the current scripts do not source any of the files in 
/etc/profile.d, though they should do so. In an interactive shell you can type 
"exec bash" to save your history and reread certain configuration files. If you 
do this from a login shell, the new shell will not be a login shell, but it will still 
have shell level 1. In this case /etc/profile is not sourced, and /etc/bashrc 
does not source the files from /etc/profile.d because it thinks /etc/profile 
already did. 
 


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