6

I'm working on a CentOS 5.9 machine, and I simply want to type

sudo vi somefile

and have my trusty vim with syntax highlighting, etc. This seems simple enough, but after many attempts, it's still not working.

root@localhost> which vi alias vi='vim' /usr/bin/vim root@localhost> sudo which vi /bin/vi root@localhost> sudo -i which vi /bin/vi root@localhost> sudo -E which vi /bin/vi

I logged in as root to ensure that by default vi somefile invoked vim. It did. I also tried to preserve the environment with -E and run the login scripts with -i. That did not work. In both my .profile and /etc/environment, I export the EDITOR as vim, and set vi as an alias to vim.

I also commented out a env_reset line in /etc/sudoers.

What else should I try? I didn't think replacing vi with vim would be so difficult, and I really like to understand what is going on here.

Improve this question

3 Answers 3

Reset to default
11

That's what the command sudoedit is for. It creates a temporary copy that is edited in the users environment. It consults SUDO_EDITOR, VISUAL and the variable EDITOR to find a suitable binary. After the edit the copy overwrites the original file.

Improve this answer
5

In case you always want to use vim instead of vi, you can just

$ sudo ln -s /usr/bin/vim /usr/local/bin/vi

(This assumes you have /usr/local/bin before /bin in your PATH.)

Granted, it's a (system-local) hack, but quite simple and effective.

Improve this answer
2
  • Bad practice to create symlinks on the fly. Better to either create a ~/bin/ directory and create a symlink in there and add ~/bin/ to PATH or to use the EDITOR variable and pass it along when sudoing by editing the sudoers file. Commented Apr 18, 2013 at 15:05
  • 1
    @mtahmed The ~/bin/ and PATH doesn't help much when the problem is around cross-user launches. I also have less reservations about symlinks (especially in .../local/... dirs), but YMMV. Commented Apr 18, 2013 at 15:17
1

I believe that the reason for the observed behavior may be found in the PATH variable. It is possible that as a regular logged-in user the segment /usr/bin comes before /bin, while when sudoing as root, the segment /bin comes before /usr/bin.

If so, the difference can be traced to either one or both of the following origins. If the value of PATH is different when using sudo, this points to the secure_path configuration parameter, typically set in /etc/sudoers or one of the /etc/sudoers.d/* files. However, if the value of PATH is different when logged-in as root (whether a first-level login or with sudo's -i/--login switch), this points to a startup file such as /etc/{profile,profile.d/*} and /etc/{bashrc,bash_*}.

I don't have a CentOS 5 installation handy, but my Alma 8 server gives the following:

## As a regular logged-in user $ echo $PATH /home/me/.local/bin:/home/me/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin ## Sudoing as root (notice the reverse order) $ sudo bash -c 'echo $PATH' /sbin:/bin:/usr/sbin:/usr/bin ## Sudoing as myself (same value) $ sudo -u me bash -c 'echo $PATH' /sbin:/bin:/usr/sbin:/usr/bin ## Indeed... $ sudo grep secure_path /etc/sudoers Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin

You might also give a quick glance at sudo's env_keep parameter and add VISUAL and EDITOR to the list of kept variables if not already there, but since you mentioned that env_reset was turned off, it probably won't change much.

Improve this answer
1
  • Oh... Ha, ha! Just saw the date that the original question was posted at. I'll nonetheless leave my reply --- now that it's all written — in case someone else runs into the same question. Commented Jul 18, 2022 at 22:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.