[178] in athena10
Re: System Dotfiles (was Re: /svn/athena r22913
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Wed Apr 23 15:14:49 2008
Date: Wed, 23 Apr 2008 13:57:59 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
cc: athena10@MIT.EDU
In-Reply-To: <1208926549.5864.88.camel@error-messages.mit.edu>
Message-ID: <Pine.LNX.4.64L.0804231056240.23969@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Looking through a random sampling of the Athena documentation on
http://web.mit.edu/olh and http://web.mit.edu/answers, few of the commands
in that documentation are dependent on what shell one is running (simply
running commands, along with simple pipes are redirection into files are
all unchanged). They do of course mention the prompt in many places
(though in the majority, the prompt is not displayed when running commands
is suggested).
The primary incompatability between bash and tcsh that might show up in
documentation is the use of "export" in bash and "setenv" in tcsh. If you
Google for
setenv site:web.mit.edu/answers [18 hits]
setenv site:web.mit.edu/olh [16 hits]
setenv site:web.mit.edu/acs [9 hits]
you get a total of less than 50 hits, and most of the ones on web/olh are
release notes for old Athena releases and thus probably don't matter.
There are only 243 hits for setenv on web.mit.edu at all (and most of them
are in people's home directories), so someone could even go through all of
them in a day and compile a list of everything that's documentation, if
one wanted to be really thorough. Further, the updates one needs to make
are doable with a short perl script (it's not quite a regexp since setenv
is mentioned both in prose and in code, but whether the next word is in
all caps is a fine heuristic for whether it is code), followed by manually
checking that the page looks right. I'm not sure where else I should be
looking for Athena documentation, but it doesn't look like the setenv
documentation update would take more than a day's work to get right.
You'd also need to totally rewrite
http://web.mit.edu/olh/Dotfiles/Dotfiles.html, but that may need to happen
anyway. I also searched for "noclobber". Interestingly,
http://web.mit.edu/answers/unix/unix_csh_redirect.html seems to think
"noclobber" isn't set by default; but this is the only reference to it
other than on the general dotfiles page.
If you also care about changing the prompt everywhere it appears in
documentation, there are more refererences to it, but it is work that can
be done with a regular expression. Google sucks and doesn't support
searching for "athena%", so I can't get data on this easily, but I'm sure
someone can grep for "athena%" in the stock answers and get a feel for
things.
I'm not counting screenshots, since Ubuntu looks different from the
current Athena look (and my current understanding is the "console" is
going away), so they're getting replaced anyway.
I agree that the transition will require some release engineering. The
main tricky thing will be people's dotfiles -- both that some people won't
have the .bashrc that includes the system .bashrc (which I've already
proposed a solution to, though we'd want to be sure that solution was
completely deployed before switching shells), and that commands they ran
in their .cshrc.mine will no longer work. If one were to go with
"switching everyone from tcsh to bash", we could probably notify them
using get_message (or email) and point them to documentation on how to
translate their dotfiles. We might also want to make "setenv" point
people to this documentation for a transitional period, since I think
that'll be the most common difference.
I don't think that Athena can stick with tcsh forever, so this
transitional work must happen at some point. Yes, there will be a lot of
support calls. But they'll probably all happen in a short interval which
can be planned for in advance (e.g. SIPB can make sure the SIPB office is
well-staffed during business hours that week, if you want to direct people
there, OLC can make sure they double-cover shifts that week, etc.).
It's worth keeping in mind that Ubuntu is fairly bash-centric; for
example, they added a feature to tell you what package to install to get a
program that you try to run that isn't installed by adding some code to
the system bashrc. So, if our users install Athena on their Ubuntu
machine (which rumor has it IS&T is considering recommending to freshmen
in the Fall), they'll suddenly find that they stop getting Ubuntu's
friendly command-not-found messages.
-Tim Abbott
On Wed, 23 Apr 2008, Greg Hudson wrote:
> I'll go over this in detail tomorrow or Thursday. Some of the items are
> probably a good idea. But a general response:
>
> I don't like being in the situation of sticking users with an unusual
> default shell (tcsh) and overriding the native operating system's shell
> defaults without compelling reasons. Most of that situation was
> inherited from before my time.
>
> However, even in the Unix world, focus has shifted away from the
> command-line as the usual way for users to get stuff done, except when
> following instructions in documentation. From a picking of battles
> perspective, I am not sure we want to get incur the documentation and
> support pain of making substantial changes to the current situation.
>
> In particular, I don't see how to get from tcsh to bash as the default
> shell without inordinate pain. Either we switch the shells of existing
> users, or we only switch the shells of incoming users. The former is
> highly discontinuous for any user who makes much use of the shell (which
> may not be a lot of users, but is probably enough to generate a lot of
> support calls) and the latter creates a major fork in documentation and
> support.
>
> I'm also not convinced that now is an especially good time to be making
> changes of this nature. If this were the 2.0 release of a piece of
> software, we would want to pile all of the incompatible changes in at
> once on the assumption that people will stick with 1.x until they're
> ready to face the combined pain of the upgrade. Athena isn't a
> voluntary upgrade; one day the cluster machines are all running the new
> release and cluster users have to accept it whether they want to or not.
> As such, when you're going to do something painful in an Athena release
> upgrade, you don't necessarily want to compound it by doing something
> else painful at the same time.
