[5020] in testers
Re: linux 9.0.10: tcsh/csh.login
daemon@ATHENA.MIT.EDU (John Hawkinson)
Tue Jul 17 10:37:53 2001
Date: Tue, 17 Jul 2001 10:37:45 -0400
From: John Hawkinson <jhawk@MIT.EDU>
To: Mitchell E Berger <mitchb@MIT.EDU>
Cc: testers@MIT.EDU
Message-ID: <20010717103745.W4333@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200107170706.DAA01791@byte-me.mit.edu>
Mitchell E Berger <mitchb@MIT.EDU> wrote on Tue, 17 Jul 2001
at 03:06:44 -0400 in <200107170706.DAA01791@byte-me.mit.edu>:
> > Specifically, /bin/athena/tcsh is built to source /etc/csh.cshrc,
> > which sources /etc/profile.d/*.csh, including /etc/profile.d/colorls.csh.
> ...
> >
> > I think that /etc/csh.cshrc should be zapped.
>
> I think this would be a bad change to make. Colorized ls is, as far
> as I know, a Linuxism, perhaps a RedHatism, and almost all the Linux
> users I know are used to and love the fact that it's colored.
OK, clearly I need to be a bit more rigorous in my explanation
and issues; I thought most people were familiar with them.
There are two seperate issues:
I Should we have color ls enabled
II If we have it enabled, What mechanism should enabled it?
> In fact, several have seen me working on my Solaris box and asked
> why ls isn't producing color.
This strongly, to me, argues in favor of making it consistent -- turning
it off under Linux or on under Solaris.
> ls is not an Athena program; it's a system binary and we usually
> stay away from changing the behavior of as many of them as possible.
Right, but in this case, it's a shell alias.
> If we get rid of the color, it will be missed. It's certainly
> possible to use a TERM setting that won't do color if you vehemently
> don't like it - that's an easy customization; reinstating color if
> we blow away the file won't be an easy customization.
Actually, that's completely the wrong way to do it.
I. Should we have color ls enabled?
a) Experienced unix users don't like it, because it is different and
that difference is abhorrent. This is really a religious issue,
and one of how we introduce change in the environment. I don't think
this is an extremely strong argument, but I do think that
enough people probably prefer the traditional ls behavior that it
should be a factor in the decision.
b) Platform consistency. Within reason, local customizations should be
consistent across platforms. We generally don't build binaries just
to make operating systems consistent if we can't help it, but we
try to make sure that their options are set equivlanetly. Offering
color ls under Linux and not under Solaris seems poor. If we are to do
this, we should do it consistently.
c) Color ls is equivalant to doing an "ls -F" every time you do ls. That
means that ls will stat() every file it is listing, rather than simply
dumping the listing. For extreme die-hards and pedants, this can be
noticable on local disk. For just about everyone, this is noticable
over AFS. If the network is having a bad day (certainly not the norm
around here), it can be debilitating.
d) Aesthetically, it is a stark departure from the monochromicity of
terminal windows. I think it does not fit well with that
monochromicity.
II. If we have it enabled, What mechanism should enabled it?
a) It should be enabled in a way that does not force people to use it.
b) Athena dotfile customizations have always been done as part of
/usr/athena/lib/init/*, and this allows them to be one central
place for users to look for system-wide dotfiles and override them
as they see fit. The /etc/csh.cshrc mechanism allows no overriding.
In this case, aliases may be removed with "unalias', but there's no
way to prevent the script from being executed. It seems a poor
precedent, since in the future, someone might put something there that
is not trivially overridden and actually changes some state.
c) In the school of system administration that I believe in, files like
/etc/csh.cshrc should be reserved for machine-specific customizations,
and site-wide customizations should be handled through another
mechanism. It seems quite clear to me that color ls is not a machine-
specific choice (we don't have local system administrators of each
cluster machine making such decisions!), but a site-wide choice.
In summary:
I think color ls is a bad idea, and we should disable it. I can understand
others might feel differently, though I'd challenge you to provide a
rigorous argument other than "some people like it."
If we do choose to keep it enabled, we should change the method in which it
is enabled to be consistent with our environment. Hopefully we would also
make it consistent across platforms.
--jhawk
