[182] in athena10
Re: System Dotfiles (was Re: /svn/athena r22913
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Apr 24 11:05:46 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Timothy G Abbott <tabbott@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <Pine.LNX.4.64L.0804221932280.23969@vinegar-pot.mit.edu>
Content-Type: text/plain
Date: Thu, 24 Apr 2008 11:05:02 -0400
Message-Id: <1209049502.5864.124.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
The promised detailed response:
On Tue, 2008-04-22 at 21:35 -0400, Timothy G Abbott wrote:
> - 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.
Agreed, although I'm also willing to let this slide if the practical
impact is small.
> - 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.
Agreed; this always bugged me. This will probably bite a few people (I
saw a fair amount of "cc myprogram.c" and "a.out" in my days in the SIPB
office) but having . in the path is fundamentally insecure.
Although, without using the archaic .path file or abandoning the system
dotfiles, there's currently no way to avoid having . in the path, which
is poor.
> - Whether we want to set the noclobber option. I think we don't.
Ambivalent, tending towards disagreement. Changing from a safer default
to a less safe one is worrisome, even if we never had the right to
choose that default initially. It's easy to turn off for those who
don't like it so I don't see a lot of benefit to changing this.
> - 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.
Don't really care either way.
> - 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.
I think we can ditch this under bash but need to keep it under tcsh.
The main program affected is emacs, and bash's maintainenance of the PWD
variable fixes the problem there.
> - 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.
Sure, we can enable it for the sake of Debian systems.
> - 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.
I don't totally understand what you're proposing with this one.
> - Whether we're intending to switch the default shell away from tcsh. I
> think we should.
Per prior discussion, I am willing to do a phased transition to bash if
documentation and support are willing to deal with the two different
classes of users. My previous impression was that this burden was
unacceptable to them, but based on Jonathan Reed's response that might
not be the case.
We would need to fix the current major problems with bash support first.
Right now the xsession is always executed under tcsh, which means (1)
your .cshrc.mine and .environment get used for graphical logins even if
you're a bash user, (2) there is no global .bash_environment setup for
graphical logins, (3) .cshrc.mine is the only way to get "skip"
variables and the like to affect xsession behavior, and and
(4) .startup.X is always executed under tcsh and has no bash equivalent.
Right now bash users typically create their own .xsession scripts to
work around this lossage.
(Also, .startup.tty is currently executed with whichever shell you use,
which isn't in keeping with the other dotfiles where different names are
used for the bash ones. This isn't an issue for changing the default
shell, and may be tolerable.)
The most straightforward solution is to fork xsession into bash and tcsh
versions and make /etc/athena/login/Xsession decide which one to use
based on the user's shell. This isn't really ideal since xsession is a
big script, but I'm willing to accept it at this point. The alternative
is a bit more intricate: make the majority of xsession a /bin/sh script
which gets executed from a shell-dependent wrapper. The wrapper sources
the user's dotfiles and sets environment variables based on the "skip"
variables in the tcsh case (in the bash case users can be told to set
environment variables directly). The main xsession script would
execute .startup.X (or perhaps the renamed bash one if we go that route)
in a subprocess using the user's shell.
> - Whether to change their API so that they are included from
> /etc/bash.bashrc (or whatever) rather than the user's ~/bashrc file.
No objection in principle. My main concern is that this would make it
harder to deliberately not use the Athena dotfiles, and would cause the
Athena dotfiles to infiltrate and possibly break local accounts which
are currently kept alone.
Users who have chosen not to use the Athena dotfiles in their Athena
homedirs are considered to be on their own from a support point of view,
but we should at least make it easy for them to turn off the Athena
behavior in Athena 10 (or whenever we introduce this.)
Local accounts could be handled by having the Athena dotfiles do nothing
for homedirs not beginning with /mit, perhaps.
