On Tue, Feb 29, 2000 at 10:38:50AM +0900, Tomohiro KUBOTA wrote:
> P.S. I think we still *need* a way of USER-LEVEL (not SITE-LEVEL)
> configuration like /usr/bin/sensible-x-terminal and $XTERM.
Some notes: this isn't needed on all systems, or even a majority of
systems. Most people who share a single system are actually likely to come
from a single country; and when they don't, at the very least they're less
likely to be running X programs anyway (since they'll probably be remote).
As such, this doesn't need to be a default. Also, starting up an xterm
isn't *that* speed critical anyway, so a shell script isn't really *that*
horrible an idea.
The attached perl script might be a good way of going about
this. Basically, put it in /usr/local/bin, or somewhere similarly
out of the way, and change the /etc/alternatives links you want user
configurable to point to it instead. Then tell your users to set, eg, the
environment variable ALT_editor to "xemacs" or "vim" or "nvi" or "nano"
to get whichever editor they prefer coming up when /usr/bin/editor is
invoked. If they don't have ALT_editor set, it'll just default to the one
with the highest priority. (The only way of manually overriding the system
default with this is a setting in /etc/profile, or /etc/environment or so)
The benefits of doing it this way is that it's completely optional:
you don't have to use it at all if you don't want to; and it can be
maintained completely separately to which ever set of alternatives you
want. The alternatives do have to accept similar command line arguments
to be particularly useful, of course.
This could very easily be generalised and packaged with, perhaps, the
following changes:
* rather than use environment variables, look at
~/.alternativesrc, or, failing that, /etc/alternativesrc for
defaults. This would be more compliant with policy, and the
slowdown is still pretty negligible.
* make a debconf installer script that lets you choose which
alternatives you want configurable
* expand it to handle choosing the right alternative for
the manpages (and any other secondary alternatives) too
I don't want to maintain such a thing, but I'm pretty sure I know how
to implement the above features, and I'd be happy to give any coding
hints to anyone who would like to maintain it.
Note that this uses internal dpkg information, which is theoretically
subject to change. YA reason why you should have a public API for your
data. Tsk tsk.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
alternative.pl
Description: Perl program
Attachment:
pgp7w1fXO9P8F.pgp
Description: PGP signature