On centos (and I believe many other distros) vi is aliased to vim for all users by default. However, for whatever reason vi is not aliased to vim for the root user, something that always annoys me when I forget to type vim instead of vi when using sudo and don't have vim features I've come to take for granted, like default syntax highlighting.

I understand how the aliasing is done, and programmatically why an alias doesn't exist when I sudo/su. I'm asking if there is a reason for this to be desirable behavior, ie why didn't the centos developers add an alias for root as well? Is there some sort of security or functionality issue with aliasing to vim for root users that doesn't exist for regular users? Is there a historical reason root alone should not have this alias?

Going along with that is there any harm in my adding a default alias of vi to vim for the root users on servers I maintain? And if I was to do it is there a preferable method I should use to go about it (or more accurately any method I should avoid using for security reasons?)

I'm asking if there is a reason for this to be desirable behavior, ie why didn't the centos developers add an alias for root as well? Is there some sort of security or functionality issue with aliasing to vim for root users that doesn't exist for regular users? Is there a historical reason root alone should not have this alias?

if you notice for root versus users on echo $PATH you will see a much shortened list... by default

It is basically a security mentality for a default security posture for linux out of the box... for those people who wish to just install and go and expect everything to be set up with regards to security.

Going along with that is there any harm in my adding a default alias of vi to vim for the root users on servers I maintain? And if I was to do it is there a preferable method I should use to go about it (or more accurately any method I should avoid using for security reasons?)

for the most part, no there is no harm adding aliases to be available for the root account. Just be mindful of how and where you do it. The security mentality assumes something like this may happen and that would be an attack vector and one of many means to hack a system. Security mindset = minimize or prevent any/all attack methods hence no aliases.

fwiw, I use SLES and have used RHEL. I prefer to edit /etc/bash.bashrc.local and /etc/csh.cshrc.local to add my aliases, this works for non-privileged users. And these two files are owned by root.rootwith permissions -rw-r--r--. For root, I simply edit /root/.bashrc.

aliases do not circumvent basic security policies, if they do then the problem is not with the alias it's with something else.

This question is verging on soliciting personal opinion. An administrator is allowed to set up their system in such a way that it suits them, and if the default setup is annoying you I would suggest that you change it.

However...

The root user is not an ordinary user, and every action taken at the interactive prompt while logged in as root should ideally be carefully considered. To remind an admin that they are logged in as root, the root prompt in most shells are by default different from the default prompt for privileged users, and indeed, working at a root prompt should remind you that you actually shouldn't be there for very long, if at all¹.

One reason vi is not aliased to vim might me that in a situation where shared libraries have gone AWOL (due to a disk failure or accidental deletion), vi may be a static executable that would work anyway (or it may be linked with libraries from another path), allowing the administrator to edit files to get the rest of the system up and running again.

The same reasoning can be applied to other "bells and whistles" that ordinary users may enjoy. In situations where an admin may be forced to bring up an interactive root shell, the dependencies of the extra features may simply not be available.

¹_{Working at a root prompt, you have no audit trail of the commands that you have typed. It is therefore better to use facilities such as sudo to do root-related tasks since sudo by default logs who does what when. This is extra important on systems where more than one person has admin rights and on corporate systems.}

Decisions like this usually hinge upon catering to concerns about ease of maintenance and safety, albeit that security, mentioned in other answers, is a factor. Some system administrators don't want odd undocumented personal customizations for the superuser's interactive environment. They want things to behave in the standard, documented, ways; with no nasty surprises. They moreover want to avoid having to re-apply personal customizations after fresh installations, system upgrades, and so forth.

In the case of vi, aliasing it to vim potentially brings up a different program on CentOS, /usr/bin/vim instead of /bin/vi. The former is an optional "enhanced VIM" that could be present, with all sorts of features compiled in, whereas the latter is "tiny VIM" with very few optional features enabled. (Ubuntu has a similar idea.) People generally want the vi command to behave as the standard vi command, especially when doing stuff as the superuser. They don't want some enhanced whiz-bang feature or plug-in altering stuff in surprising ways; or, worse, breaking in rescue or emergency modes. They don't want all of the vi reference doco that someone doing critical work as the superuser consults, to be drastically erroneous because of such things.

This means invoking vi when the adminstrator asks for vi, not vim.

Put another way: Whereas you have come to take all sorts of VIM customizations and extensions for granted, what some other people tend to take for granted is that the superuser account does not have such customizations and extensions. They build that assumption into WWW pages, Q&A answers, and books that they write. They form habits and carry knowledge from one system to the next of what they'll get when the superuser runs vi. (And sometimes this is that it has VIMisms, ironically. One of the things that people have to learn going from a Linux operating system to FreeBSD is that vi is nvi and not any flavour of VIM at all.)

Moreover: They want not to have to remember to carry /root/.vimrc and /root/.gvimrc over hard disc changes, system reinstallations, and the like; in addition to the system-wide configuration files.

Another example of this thinking in action is the toor account on FreeBSD. It's the superuser, but with a Bourne-like shell (the Almquist shell, in fact). The root account has the TENEX C shell, and because there are decades-worth of BSD doco that show the superuser driving the system with the C shell, advice that people give is to leave that as it is, and use toor for Bourne-like interaction. The C shell is the expected environment when logging in as root, and if it came up with a Bourne-like shell for a superuser who had (say) a book of C shell instructions for administering FreeBSD, hilarity and indeed potentially disaster would ensue.

Further reading

• "vi". Shell and Utilities. Single UNIX Specification. Issue 7. IEEE 1003.1. 2018. The Open Group.


• https://askubuntu.com/questions/281886/


• Dru Lavigne (February 2009). BSD Hacks: 100 Industrial Tip & Tools. O'Reilly Media. ISBN 9780596006792.


• https://unix.stackexchange.com/a/397056/5132


• Sven Guckes (2017). Vi Clones and HomePages. guckes.net.