Bug 9950 - Put fancy stuff in ~/.bashrc, not /etc/bashrc
Summary: Put fancy stuff in ~/.bashrc, not /etc/bashrc
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash   
(Show other bugs)
Version: 6.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-03-04 04:58 UTC by Matthew Miller
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-04-14 12:29:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matthew Miller 2000-03-04 04:58:10 UTC
It's nifty to set PROMPT_COMMAND to change the title bar in xterms, but
wouldn't it be better to put this in individuals' dotfiles instead of the
systemwide one? It'd be nice for the standard /etc/bashrc to be as empty as
possible, with all fancy stuff removed to user-configurable areas. (Sure,
PROMPT_COMMAND can be set again by the user if they want to change it, but
why do it twice?)

Comment 1 Steve Coile 2000-03-05 16:56:59 UTC
I agree.

Perhaps related, note what happens when bash 1.14.7(1) does when provided with
an invalid command-line argument:

$ bash --version
bash --version
bash: --: bad option
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"

Note that those escape codes are *displayed* as shown above.

Comment 2 Pekka Savola 2000-04-14 08:49:59 UTC
If you have e.g. 100 users on a box, it can be pretty tedious to put some new
features in their .bashrc.  I like addition like this in /etc/bashrc better.
It's an opinion I guess.

A little bug:  if you have an SSH connection to somewhere and that connection
breaks, the prompt isn't refreshed to reflect to your original source HOSTNAME.

Just my 0.02c.

Comment 3 Matthew Miller 2000-04-14 12:29:59 UTC
If it's a new machine, it doesn't matter if this is in the skel .bashrc or in
the system-wide one -- everybody gets it anyway. And if it's an upgrade, a lot
of people would prefer to not have changes like this "forced" on them. If you as
the sysadmin _do_ like the change, it's easy for you to add this to /etc/bashrc,
but it's nicer for that to be your decision. (Or actually, you could use a
simple shell script to add it to the individual ~/.bashrc files.)

As for the "bug" you mention -- that's pretty unavoidable. (And one of several
reasons people may not like this feature.)

Comment 4 Bernhard Rosenkraenzer 2000-08-03 16:38:13 UTC
Users who don't like it can just undo it in their .bashrc - I think it's better
off in the system wide file so Joe Stupid User gets nice settings even after a
"What's this .bashrc file, I've never used it, open kfm/gmc click .bashrc, click
delete" session.

Comment 5 Ron Yorston 2000-10-12 09:20:08 UTC
I don't mind that there /is/ an /etc/bashrc file where admins can place
system-wide stuff.  What I do object to is Red Hat deciding what constitutes a
'nice setting' and putting it there for us.

I've just upgraded to 6.2 from 6.1, and had to waste time figuring out where the
broken PROMPT_COMMAND stuff was coming from.  Now I'm going to have to remember
to fix this crap everytime I do an installation.

It's the same with the Red Hat-supplied /etc/inputrc, which breaks vi mode in

Yes, these are only opinions, but I don't like having other people's opinions
installed by default.  Keep it policy-free, folks.

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