[173] in athena10
System Dotfiles (was Re: /svn/athena r22913
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Tue Apr 22 21:36:32 2008
Date: Tue, 22 Apr 2008 21:35:48 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <1208894197.5864.73.camel@error-messages.mit.edu>
Message-ID: <Pine.LNX.4.64L.0804221932280.23969@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Those fixes have been deployed in Debathena. Thanks for doing a careful
review of my rather large patch swiftly.
Now that we've cleaned up the system dotfiles code so that it's a bit
easier to see what it's doing, there are a few things that I think are
worth discussing regarding the details of the system dotfiles. Ideally, I
would like it to be the case that people can use essentially the same
dotfiles on their machine at home as on Athena+. For this reason, I'd
prefer it if the Athena environment did not change defaults that are not
either specifically useful at MIT (e.g. replacing the chsh binary with a
Moira-aware version) or essentially uniformly desirable (like enabling
programmable bash completion). The issues that I think we should talk
about (along with my current opinions) are:
- Whether we want to include /usr/sbin and /sbin in the default PATH (some
programs that used to be in /usr/athena/etc are now there are thus have
left PATH). I think we probably do.
- Whether we want to be adding '.' at the end of PATH (some people
consider this to be very bad practice). I think we don't.
- Whether we want to set the noclobber option. I think we don't.
- Whether we want to set IGNOREEOF (this is important if people are using
zwrite on the command line a lot, but I don't see that much these days).
I currently favor no.
- Whether we want to keep the bit of code that resets HOME (this seems to
go awry sometimes). I think we should do tests and make a decision.
- Whether we want to enable programmable bash completion (Debian has it
commented in /etc/bash.bashrc by default). I think we do. Of course,
Ubuntu does it already, so this isn't really an Athena 10 issue.
- Whether we want to add other things that are currently useful, like eval
$(lesspipe), to the system dotfiles. I think this may pass the test of
being essentially uniformly desirable.
- Whether we're intending to switch the default shell away from tcsh. I
think we should.
- Whether to change their API so that they are included from
/etc/bash.bashrc (or whatever) rather than the user's ~/bashrc file.
This has the long-term advantage that we could eventually have ~/.bashrc,
rather than ~/.bashrc.mine, be the user's configuration file. Currently,
people who copy in their dotfiles from their previous UNIXy environment
have everything break for them. I've debugged this for several people in
the SIPB office, and if we can do such a transition with no bad
consequences, I think it'd be a long-term improvement. I think such a
change could potentially be done in an essentially backwards-compatible
fashion by installing the system dotfiles into /etc/bash.bashrc.debathena
(etc.) and installing empty files in /usr/athena/lib/init.
Some of these are obviously long-term issues, but I think it's worth
thinking about them now, since it's probably much easier to do these
changes when people are already dealing with all the other consequences of
the upgrade to Ubuntu.
-Tim Abbott
On Tue, 22 Apr 2008, Greg Hudson wrote:
> The modified cshrc and bashrc files don't set a standard path at all.
> This is probably okay if the intent is to use the path set by the login
> system, but a number of comments appear to have been rendered incorrect
> by the change.
>
> Correctly constructed .path files will break because athena_path is not
> set. It should be set (set athena_path=$path) for compatibility in the
> case where a ~/.path file exists.
>
> I didn't find any other problems in a fairly careful review.
>
> (In case anyone is curious, the reason for the $athena_path contortions
> is to make tcsh avoid re-hashing the path several times during the login
> process. Really not a concern today.)
>
>
>
