Some of the symlinks created when vim is emerged start with a double-slash. I discovered this when trying to create a jailkit chroot jail. The result is that the process hangs and the vi editor is never included in the chroot jail, and any other program set for inclusion after the editor. Not sure if this is strictly considered a bug as the editor still works from the command-line. But it would be nice to have this fixed for use with automated jailkit creation scripts etc. Reproducible: Always Steps to Reproduce: 1. emerge app-editors/vim 2. ls -la /usr/bin/vi 3. ls -la /usr/share/vim/vim72/doc/gentoo-syntax.txt Actual Results: /usr/bin/vi -> //usr/bin/vim /usr/share/vim/vim72/doc/gentoo-syntax.txt -> //usr/share/vim/vimfiles/doc/gentoo-syntax.txt Expected Results: /usr/bin/vi -> /usr/bin/vim /usr/share/vim/vim72/doc/gentoo-syntax.txt -> /usr/share/vim/vimfiles/doc/gentoo-syntax.txt
I don't fully understand the problem. A double-slash is equivalent to a single slash for every path parsing code I've ever encountered. How is this 'jailkit' different?
I'm not sure but when trying to create the jail using jk_init, with the editors section containing vi, the creation of the jail hangs on trying to find the path. I wish I could provide a better explanation but when I removed the symlink and re-created it with a single slash it worked. Incidently when I changed the first symlink to the binary and re-ran jk_init it got stuck again on gentoo-syntax.txt.
(In reply to comment #1) > I don't fully understand the problem. A double-slash is equivalent to a single > slash for every path parsing code I've ever encountered. How is this 'jailkit' > different? > Actually, according to POSIX, a double slash at the beginning is not equiv to a single slash. But, more slashes are fine. /////foo == ///foo == /foo != //foo But this only applies to leasing slashes. Confusing, eh? :) I noticed that the ebuild installs the double slash, but eselect vi set 1 does not.
Okay, this looks to be a problem with app-admin/eselect-vi and is probably identical to the root cause of bug #315613... We'll see about fixing that...
Aha, this is a known issue. Should be solved by bug #260593
This should be fixed in app-admin/eselect-vi-1.1.7 After upgrading to eselect-vi-1.1.7 run 'eselect vi set vim' as root.
