[176] in athena10
Re: System Dotfiles (was Re: /svn/athena r22913
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Wed Apr 23 00:04:40 2008
Date: Wed, 23 Apr 2008 00:03:56 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: Greg Hudson <ghudson@mit.edu>, athena10@mit.edu
In-Reply-To: <CE7D6005-36A6-4C0C-A5DC-1D020FEFEE5A@mit.edu>
Message-ID: <Pine.LNX.4.64L.0804222319530.23969@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 22 Apr 2008, Jonathan Reed wrote:
>> - Whether we want to set the noclobber option. I think we don't.
>
> It's helpful, particularly for files with a longevity less than that which is
> required to show up in OldFiles. People who care can use >! to override it.
>
>> - 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.
>
> I like having this set. I'm sure I'm not the only person who has
> accidentally pressed Ctrl-D in the wrong xterm before. Putting people in the
> mindset of explicitly logging out is also a good thing, IMHO.
I don't see this issue as whether many people find them useful (clearly
many do). I think with these two features, about half of users want one
thing, and the other half want the other. Obviously, anyone can override
anything we set in the defaults in their own dotfiles. But if half the
people want to override the default we've changed (many of which will
probably be too lazy to do so), then our change of default is actively
harmful, as its primary effect is for the same command to do something
different on Athena than in their other environments that have a shell.
I do think the argument for keeping IGNOREEOF is stronger than that for
noclobber, since IGNOREEOF is a feature that enhances the zephyr
experience. But I'm not sure this outweighs the impact of the unecessary
differences from the rest of the world. I would certainly encourage
mentioning IGNOREEOF in documentation on how to use zephyr if we were to
turn it off.
>> - 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'm confused as to which bit of code we're talking about.
Search for HOME in /usr/athena/lib/init/bashrc. It's a bug workaround, so
the issue there is just that someone should find out whether the bug still
exists and do what's reasonable. Probably not worth spending any more
time discussing here.
>> - Whether we're intending to switch the default shell away from tcsh. I
>> think we should.
>
> Ugh. Are there any compelling non-religious reasons for doing this? I
> understand the desire to move away from building our own tcsh, but surely
> Ubuntu provides a working tcsh. tcsh has been the default since ~forever,
> and tons of example code and dotfiles make this assumption. For example,
> this will break things like "setup", which does not yet exist in bash.
> There's a lot of third party software and course lockers that rely on
> "setup", and changing those would require a lot of outreach. If we want to
> debate the merits of one shell over another, that's fine, but I think this is
> the wrong forum, and I think such a change is completely outside the scope of
> the project. Unless you're talking about switching the default shell only
> for accounts created after a certain date, and that would suck from a support
> standpoint.
Debian/Ubuntu has its own tcsh, though we'd need to build our own anyway
if we want ~locker to work (Debathena already does this for both tcsh and
bash). The more important issue is that tcsh lost the religious war a
long time ago, and anyone who gets experience with a shell from OS X or
Ubuntu or whatever is going to expect bash. This is not to mention the
well-documented problems with tcsh that you'll find if you google for
"csh" and "harmful".
I agree there's a lot of documentation overhaul that'll need to be done.
Frankly, switching from Red Hat to Ubuntu will involve rewriting vastly
more documentation, so that now is the optimal time to switch shells if
we're going to do it (it'll be easy to change all the prompts when we're
completely replacing the text).
I don't think we should be making long-term technical decisions based on
what will save a moderate amount of work in the short run. I suspect by
switching to bash we may actually save work on documentation in the long
term, because non-MIT-specific documentation on the web (especially the
Ubuntu wiki) will all assume that everyone's using bash, and I think IS&T
will be able to handle many issues that are not MIT-specific by giving
people pointers to the relevant parts of the Ubuntu documentation, which
is generally very user-friendly. If we do stick with tcsh, then pointing
people to the Ubuntu documentation will result in confusion, since when
the documentation tells them to run "cmd 2>/dev/null" or whatever other
thing tcsh does differently, it won't work.
I don't understand how changing the default shell affects third party
software. Third party locker software seems to work regardless of what
the user's shell is. But I guess I also don't understand what "setup"
does -- presumably it is a tool used to setup third party software
lockers?
-Tim Abbott
