[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should we implement a /etc/profile.d? (/etc/environment proposal)

[ For the /etc/environment proposal itself, go straight to the last
paragraph. ]

> > Having ls output color settings by default is a bad idea, since
> > not everyone has a color-capable terminal. It requires an option
> > to enable it, i.e., you need an alias or shell function.
>  This is easily fixable: testcolor && .... , where testcolor is some
> binary (or whatever) that check if the terminal is color capable.

Old ls was, in my opinion, way better than the one we have now.  First,
the list of colour-capable terminal types was included in /etc/DIR_COLORS,
so it was up to ls to decide whether to use colours or not.  Second,
aliases were not necessary, and that was very good; I think, aliases
should generally be avoided as much as possible, because:
 - they are a source of confusion: if there is a binary with the same
   file name as the command, people tend to expect that it is the binary
   which really gets executed;
 - they do not propagate into subshells, which is disappointing ("Hey,
   where are the colours?" after :!ls in vi, or from su).

(The second problem can either be solved by using exported shell
functions or by employing ENV - but ENV is a typical hack for users'
customisation and definitely must not be used by default in the

>  I agree that this can be discussed, but I also think that most users
> expect to see colors. They have used other distributions, they know the
> feature... many people feel disappointed when they don't get colors and
> they have to take the trouble to learn how to set it. I know that you
> would say "hey! we aren't working here for a user that get dissapointed
> when he has to read a manpage" =) I'd said that setting these things is
> part of being `friendly'... Even for experienced users... I find boring to
> have to set up all those little things in new system.

Exactly.  Monochrome ls was one of the reasons why I disliked RedHat
when I first tried it (several years ago from some Caldera CD-ROM).  By
that time I was used to Slackware's nice colour ls.  And I was not
disappointed at all when, during my first Linux installation, ls
suddenly turned out to be colourful.  "Very nice," I thought.

> > >  So.. what should we do?
> > Make sure programs work without special setup.
>  For some things, using variables is more natural... and more consistent
> with other distributions...

Right.  First, variables reflect system configuration (man uses more by
default, but when less is installed, it's often OK to tell man to use
less); second, consistency (not only with other distributions, but with
the original programs as well) is important when a user compiles a newer
or customised version of a program, or when he/she moves to or from another

I think that there may be reasons for packages to set variables in
/etc/profile (EDITOR, VISUAL, PAGER, LESS*, etc), but doing more
sophisticated things (e.g., setting aliases, evaling dircolors) does not
seem necessary.  As for ls, it's in the base, so its ugly stuff can be 
put into the base /etc/profile.  Should the necessity for a dirty hack
ever arise, there is always a possibility to install a shell script
which calls the real binary in whatever way it [binary] likes (like what
was done with Netscape under Digital UNIX).

So, to keep things simple and to reduce the overhead imposed by the
/etc/profile.d scheme (on the filesystem, dpkg database and shell
startup time) it may make sense to set up a /etc/environment file
instead which will contain variable-value pairs and will get interpreted by
each kind of shells accordingly to their syntax (it must be a very
simple loop).


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: