You are not logged in.

#1 2014-03-18 20:38:28

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

[SOLVED] What is the approved modus operandi for alternatives?

I'm a relatively new Arch user, but long time debian/Ubuntu sys admin.  When I installed the vim package recently, I was surprised to see that /usr/bin/vi was still linked to ex:

[root@gecko ~]# ls -l /usr/bin/vi
lrwxrwxrwx 1 root root 2 Nov 16  2012 /usr/bin/vi -> ex

I'm pretty sure that most people who install vim want vi to be vim, not ex.  There are many things like this where a canonical utility (vi, sendmail, c++, java) can be provided by alternative packages.  The way this is handled in debian is there is a /etc/alternatives directory which provides connectors to the default alternative:

lizard:~web$ ls -l /usr/bin/vi
lrwxrwxrwx 1 root root 20 May 17  2012 /usr/bin/vi -> /etc/alternatives/vi
lizard:~web$ ls -l /etc/alternatives/vi
lrwxrwxrwx 1 root root 16 May 17  2012 /etc/alternatives/vi -> /usr/bin/vim.gtk

This seems a bit weird at first, but it does work.  Every time you install a package with provides vi the post-install script resets the alternative link.  If you want it to be set to a previously intalled alternative, you have to reset the link by hand.  I'm wondering how, if at all, this is handled in Arch?  One solution is to make alternatives which provide the same utilities conflict, but sometimes you want to have several different packages installed that all provide some version of, say, c++.

In particular (since I will never remember to type vim instead of vi), are users expected to relink /usr/bin/vi themselves?  I could make a bash alias for this, but then would have to remember to do this for every new account on the system.

Last edited by pgoetz (2014-04-01 15:05:13)

Offline

#2 2014-03-18 20:51:32

alphaniner
Member
From: Ancapistan
Registered: 2010-07-12
Posts: 2,604

Re: [SOLVED] What is the approved modus operandi for alternatives?

In arch, there's a vi package and a vim package. Vi isn't vim. So you could uninstall vi, install vim, and make the symlink.

I just use an alias. You could modify /etc/skel/.bashrc so new users get the alias automatically.


But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner

Offline

#3 2014-03-18 21:19:43

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

Thanks for the heads up -- I had no idea the original vi was still around.  On debian/Ubuntu systems the vim package provides vi and ex; linked through /etc/alternatives.

Offline

#4 2014-03-18 21:21:19

karol
Archivist
Registered: 2009-05-06
Posts: 25,423

Re: [SOLVED] What is the approved modus operandi for alternatives?

There are even various versions of vi :-)

Offline

#5 2014-03-18 21:36:37

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

karol wrote:

There are even various versions of vi :-)

I think it would be worth considering implementing something like the debian /etc/alternatives.

If for no other reason that to keep from confusing new users.

Last edited by pgoetz (2014-03-18 21:37:06)

Offline

#6 2014-03-18 21:38:24

karol
Archivist
Registered: 2009-05-06
Posts: 25,423

Re: [SOLVED] What is the approved modus operandi for alternatives?

The ex / vi / vim / gvim is a touchy subject. Things have been changed a couple times over the years and there's no clear universal good way of doing it all.
https://bugs.archlinux.org/task/13239
https://bugs.archlinux.org/task/20778

Offline

#7 2014-03-18 22:02:13

progandy
Member
Registered: 2012-05-17
Posts: 2,146

Re: [SOLVED] What is the approved modus operandi for alternatives?

If you want to link vi to vim globally, you could do something like this. If you want, you can also create a vi-alternatives package that links to /etc/alternatives/vi. Then let root modify that symlink. If you still want ex, then create your own ex-package (maybe install as /usr/lib/ex/ex or /usr/bin/exex)

pkgname=vi-vim
pkgver=1
pkgrel=1
pkgdesc="link vi to vim"
arch=(any)
url="http://www.vim.org"
license=(unknown)
depends=(vim)
provides=(vi)
conflicts=(vi)

package() {
  install -dm755 "$pkgdir/usr/bin"
  ln -s vim "$pkgdir/usr/bin/vi"
  ln -s vim "$pkgdir/usr/bin/ex"
  ln -s vim "$pkgdir/usr/bin/vedit"
  ln -s vim "$pkgdir/usr/bin/view"
  ln -s vim "$pkgdir/usr/bin/edit"
}

If you want to do it for a single user, you can create your own ~/bin, prepend it to your PATH and create the symlinks there. (you can put that all in /etc/skel)

Last edited by progandy (2014-03-18 22:27:25)

Offline

#8 2014-03-18 22:54:15

sitquietly
Member
From: Moscow, Tennessee
Registered: 2010-07-12
Posts: 216

Re: [SOLVED] What is the approved modus operandi for alternatives?

pgoetz wrote:
karol wrote:

There are even various versions of vi :-)

I think it would be worth considering implementing something like the debian /etc/alternatives.

If for no other reason that to keep from confusing new users.

I was a new user once.  I used Debian then, and I found "alternatives" to be confusing.  In contrast I find Arch's handling of the vi family to be straightforward and not confusing at all. big_smile
You'll get used to it and then it will feel good.

Offline

#9 2014-03-19 08:34:02

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

karol wrote:

The ex / vi / vim / gvim is a touchy subject. Things have been changed a couple times over the years and there's no clear universal good way of doing it all.
https://bugs.archlinux.org/task/13239
https://bugs.archlinux.org/task/20778


So in cases like this it would be useful to have a mitigation system which allows people to sensibly enjoy their personal preferences.  I agree that /etc/alternatives is a bit confusing, but I can't think of a better way of doing this.  Modifying anything outside of /etc in a package-based system is not a good idea, since it's not reversible using pacman.  Progandy suggested building a package just to create these symlinks.  This seems like overkill, and would require a similar package for everything in need of an alternative.

Offline

#10 2014-03-19 08:36:31

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

progandy wrote:

If you want to link vi to vim globally, you could do something like this. If you want, you can also create a vi-alternatives package that links to /etc/alternatives/vi. Then let root modify that symlink. If you still want ex, then create your own ex-package (maybe install as /usr/lib/ex/ex or /usr/bin/exex)

pkgname=vi-vim

Under the circumstances, this seems like it might the best way to go.  However, I'm not sure I would also provide links to ex or edit (and wasn't even aware of vedit).  ex and edit behave fundamentally differently from vi, so linking these would be confusing.  vedit seems to behave like vi, but I'm not sure that linking this to vim would set the appropriate options.  I use view --> vim all the time, so know that this works properly.  The man page for vedit doesn't tell me what special options are being set, so I'm not sure how to test this without investing more time than I'm interested in putting into this, as I'm a very experienced vim user and unlikely to ever use vedit.

Thanks for the suggestion -- that was helpful!

Last edited by pgoetz (2014-03-19 08:55:24)

Offline

#11 2014-03-19 18:53:24

sitquietly
Member
From: Moscow, Tennessee
Registered: 2010-07-12
Posts: 216

Re: [SOLVED] What is the approved modus operandi for alternatives?

pgoetz wrote:
karol wrote:

The ex / vi / vim / gvim is a touchy subject. Things have been changed a couple times over the years and there's no clear universal good way of doing it all.
https://bugs.archlinux.org/task/13239
https://bugs.archlinux.org/task/20778


So in cases like this it would be useful to have a mitigation system which allows people to sensibly enjoy their personal preferences.  I agree that /etc/alternatives is a bit confusing, but I can't think of a better way of doing this.  Modifying anything outside of /etc in a package-based system is not a good idea, since it's not reversible using pacman.  Progandy suggested building a package just to create these symlinks.  This seems like overkill, and would require a similar package for everything in need of an alternative.

It feels like I'm missing something so I'll just ask if someone can "argue" in favor of Debian alternatives to show me how it could be "a nice thing to have".

I found the explanation on the Debian wiki that

The Debian alternatives system creates a way for several programs that fulfill the same or similar functions to be listed as alternative implementations that are installed simultaneously but with one particular implementation designated as the default. For example many systems have several text editors installed at the same time. The vi program is a classic example of an editor that has many implementations such as nvi, elvis, vim, etc. but which one should be designated as the default?

The way I'm seeing this, the only goal (let's stick to vi/vim/elvis/...) is to be able to type

vi

and actually get the original Bill Joy vi/ex, or get vim, or get nvi, or get elvis, or something else.

What I'm not seeing is how that is an advantage over having to type vi to get the lean and clean vi/ex, vim to get the bells and whistles improved vi, elvis, etc.]
Of course I set my EDITOR env variable to the one I want "by default" inside scripts and utilities.  If I run my vi command through a symlink I will have created "states" in my system and consequent need for hidden magic to manage the state (the symlinks).  One day a user can type vi and get his beloved vim, another day he can type vi and get elvis and say "WTF?!"  Then he has to go read up on the "Alternatives System" and learn how to control the state of his system.  That seems confusing to me.

Offline

#12 2014-03-19 20:03:09

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

sitquietly wrote:

What I'm not seeing is how that is an advantage over having to type vi to get the lean and clean vi/ex, vim to get the bells and whistles improved vi, elvis, etc.]
Of course I set my EDITOR env variable to the one I want "by default" inside scripts and utilities.  If I run my vi command through a symlink I will have created "states" in my system and consequent need for hidden magic to manage the state (the symlinks).  One day a user can type vi and get his beloved vim, another day he can type vi and get elvis and say "WTF?!"  Then he has to go read up on the "Alternatives System" and learn how to control the state of his system.  That seems confusing to me.

You might have convinced me that the current Arch way of dealing with vi/vim/gvim/elvis is better; however I will still make a case for using the alternatives approach.  First, I assume you'll agree that someone who has only ever used vim will find traditional vi nearly unusable, if for no other reason than vim allows you to move around and even delete characters while in insert mode.  I was using UNIX on one of the original Sun workstations (hence both learned on classic vi and have been using UNIX for a long time) but can no longer use classic vi because of insert mode behavior and multiple undo/redo levels, all of which I use a lot.  Also, it's not just about vi -- I use view more than I use vi.  We run a system with a very large number of end users, many of whom I never see.   Linux-savvy college students set up accounts in order to use our labs, and we also have visiting faculty, etc..  Most of the college kids have probably never seen classic vi; they've only ever used vim, which is what you get when you type vi on at least Debian, Ubuntu, and Linux Mint systems.  Further Vim is readily available for MS Windows systems, and the vi on Mac OS X is also vim.  If these users type vi and get classic vi, they will be confused by the odd behavior and will either assume our system is broken or will log a support call.  Given modern computers, the difference in resource consumption between classic vi and vim must be negligible.  If I'm going to worry about resources on the system, I'll look first to firefox and chrome which are currently consuming 706MB and 131MB of resident memory on my system respectively.  Under these circumstances the easiest thing to do is just give everyone the most powerful program and call it vi; hence the existence of /etc/alternatives.  In this case KISS means keep it simple for the users.  Frankly, I had no idea people were still using classic vi and am somewhat hard pressed to understand why anyone would do so.  I can understand using vim-tiny when a system is booted from a ram disk, but otherwise why not just live a little and get yourself a fully functional editor?

However, I completely agree about the symlinks being somewhat of a kludge.  /etc is the place where users are allowed to hand modify configuration files, so it's not too much of stretch to have the package manager leave any symlinks in /etc/alternatives that have been user-modified unchanged, even when a new package is installed that wants to reset the symlink.

Last edited by pgoetz (2014-03-19 20:04:22)

Offline

#13 2014-03-19 21:07:36

sitquietly
Member
From: Moscow, Tennessee
Registered: 2010-07-12
Posts: 216

Re: [SOLVED] What is the approved modus operandi for alternatives?

pgoetz wrote:
sitquietly wrote:

What I'm not seeing is how that is an advantage over having to type vi to get the lean and clean vi/ex, vim to get the bells and whistles improved vi, elvis, etc.]
Of course I set my EDITOR env variable to the one I want "by default" inside scripts and utilities.  If I run my vi command through a symlink I will have created "states" in my system and consequent need for hidden magic to manage the state (the symlinks).  One day a user can type vi and get his beloved vim, another day he can type vi and get elvis and say "WTF?!"  Then he has to go read up on the "Alternatives System" and learn how to control the state of his system.  That seems confusing to me.

You might have convinced me that the current Arch way of dealing with vi/vim/gvim/elvis is better; however I will still make a case for using the alternatives approach.  .....  In this case KISS means keep it simple for the users.  Frankly, I had no idea people were still using classic vi and am somewhat hard pressed to understand why anyone would do so.....

Thanks, I understand your reasoning and it makes sense in your environment to have vi invoke vim, by one means or another (unless your students learn vi from Robbins book, Learning the Vi and Vim Editors, and then expect vi to behave differently from vim).  I have the same experience using vi of course and can't actually use vi (you used Bill Joy's original vi !! smile ) on a daily basis because the simplistic undo behavior would trip me up.  But I do a lot of working in minimal environments for bootstrapping a linux system.  During the bootstrapping process I have to go through a phase of very minimal dependencies and vi is ideal for that.  It's there when almost nothing else is, and I hate nano.  I've used vi in work on an embedded system and then vi and ex seemed extravagantly powerful compared to the line editors I had used in the dark ages.

Offline

#14 2014-04-01 15:04:48

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

I realized after giving this some more thought that progandy's suggestion to create a package which conflicts with vi and creates the links vi ---> vim, view ---> vim is the right way to solve this problem.   This way if vi is installed, it will get un-installed, and attempts to re-install vi will indicate the conflict with the links.

I built and tested the package and will probably put it out on AUR so that other people can use it as well.

Offline

#15 2014-04-01 15:12:45

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,424
Website

Re: [SOLVED] What is the approved modus operandi for alternatives?

You can name the package "vi-fake-like-debian"! big_smile

I'm just teasing. ABS / makepkg / pacman really are amazing. If someone told me that the best solution for such a simple problem was to "make a package" in any other operating system I would have thought they were nuts. smile

Offline

#16 2014-04-01 17:12:00

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

I named it link_vim_to_vi, but am open to suggestions for a better name.  I thought about something more cryptic, but in the end decided that descriptive would be best.

Oh, and I'm pretty sure it's not just debian/debian-derivatives that link vi to vim.  I just checked a CentOS system which similarly does this and also uses the /etc/alternatives approach to sorting out what vi will be.

Offline

#17 2014-04-01 17:32:56

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,424
Website

Re: [SOLVED] What is the approved modus operandi for alternatives?

You want my opinion? I'd probably call it "vi-symlink" (hyphens are more common on the AUR than underscores). But I don't think it really matters. Just make sure you give it a good description, and describe it in even more detail in a comment. smile

Offline

#18 2014-04-01 17:48:31

bstaletic
Member
Registered: 2014-02-02
Posts: 576

Re: [SOLVED] What is the approved modus operandi for alternatives?

Wouldn't aliasing be easier (with modified /etc/skel/.bashrc)? What are the benefits of making a package?

Offline

#19 2014-04-01 18:34:16

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,424
Website

Re: [SOLVED] What is the approved modus operandi for alternatives?

EDIT: Oops. Never mind.

Last edited by drcouzelis (2014-04-01 18:35:17)

Offline

#20 2014-04-01 18:40:08

progandy
Member
Registered: 2012-05-17
Posts: 2,146

Re: [SOLVED] What is the approved modus operandi for alternatives?

bstaletic wrote:

Wouldn't aliasing be easier (with modified /etc/skel/.bashrc)? What are the benefits of making a package?

Some applications search for your $EDITOR in $PATH. That circumvents shell aliases. You could create the symlinks in /usr/local/bin/, but then you still have a little risk if some application calls /usr/bin/vi or /bin/vi directly.
Replacing vi directly at the source makes it foolproof if you want to force it for all users.

Offline

#21 2014-04-01 20:04:08

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

progandy wrote:

Replacing vi directly at the source makes it foolproof if you want to force it for all users.

I'm pretty sure that if you don't have a .vimrc file vim runs in vi compatability mode, so forcing vim on users is hardly much of a burden.  As mentioned, all debian and Redhat derivatives appear to do this already, as does Mac OS X.

Offline

#22 2014-04-01 20:07:01

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 188

Re: [SOLVED] What is the approved modus operandi for alternatives?

drcouzelis wrote:

You want my opinion? I'd probably call it "vi-symlink" (hyphens are more common on the AUR than underscores). But I don't think it really matters. Just make sure you give it a good description, and describe it in even more detail in a comment. smile

Do you mean a comment in the PKGBUILD file?  I've been wondering how one includes a more extensive description when creating packages; PKGBUILD doesn't seem to have a field for this.  Let me think about the vi-symlink name; I think I like it better than what I came up with.

Last edited by pgoetz (2014-04-01 20:07:45)

Offline

#23 2014-04-01 20:20:23

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,424
Website

Re: [SOLVED] What is the approved modus operandi for alternatives?

pgoetz wrote:

Do you mean a comment in the PKGBUILD file?

Nah, just on the AUR page after you upload it.

Offline

#24 2014-04-01 20:34:45

WorMzy
Forum Moderator
From: England
Registered: 2010-06-16
Posts: 5,059

Re: [SOLVED] What is the approved modus operandi for alternatives?

Comments in the PKGBUILD are useful too. People (are supposed to) read the PKGBUILD before they build the package, so it's a good place to put anything you want to convey, but doesn't fit into the PKGBUILD fields.


Sakura:-
Mobo: ASUS P8Z77-V PRO // Processor: Intel Core i7-3770K 3.4GHz // GFX: nVidia GeForce GTX 970 Ti // RAM: 32GB (4x 8GB) Corsair DDR3 (@ 2133MHz) // Storage: 1x 3TB Seagate SATAII 5x 1TB Samsung SATAII, 2x 120GB Corsair SSD

Offline

Board footer

Powered by FluxBB