Description of problem: Vim can no longer open files encrypted with vim (using blowfish2) Vim can no longer encrypt files. The ":X" returns an error Version-Release number of selected component (if applicable): 9.1.2128 How reproducible: open any file or create a new one with vim. Enter ":X" and the system responds with "E319: Sorry, the command is not available in this version" Steps to Reproduce: 1. Open vim 2. Type: :X 3. Observe the error: E319: Sorry, the command is not available in this version Actual results: E319: Sorry, the command is not available in this version Expected results: VIM should prompt the user for a password in order to encrypt the file. If a user tries to open an already-encrypted file, it should prompt for the password to open it. It appears VIM isn't complied with encryption support. Additional info:
Hi Brent, thank you for the report! Are you sure you run Vim and not Vi? Would you mind sharing output of ':ver'? FTR I have the same patchlevel and encryption via blowfish2 works for me.
Well, that's weird. I have vim and vim-minimal installed. I see that "vi" by itself runs the vim-minimal binary, which does not have encryption support. It would appear some update somewhere changed my "vi" command to the vim-minimal binary instead of using vim. I've NEVER typed "vim" in my life as a command, yet I always had encryption. It appears something else changed on my system (well, all five different fedora systems that I administer) where the "vi" command changed to the "vim-minimal" binary...which is just "vi" and lacks encryption. So...thanks for identifying that issue...but now I'm unclear what caused it in the first place. Not a bug with vim then, a different issue where "vi" no longer calls the vim binary. If I remove "vim-minimal" from my system, then the "vi" command returns "command not found". Perhaps "vi" was a symlink to vim and some update removed that? Strange.
Well, it is actually Vim bug - lately I have removed vi wrapper because users complained they cannot start Vi under sudo option NOEXEC (because the wrapper was script which started the real Vi binary, so setting NOEXEC on it prevented starting the binary), and old Vim aliases did not work everywhere in the past (they need bash restart to start working after installation and they did not work under sudo), so I tried to avoid incomplete solution. Alternatives explicitly mentions Vi->Vim situation as incorrect use of alternatives in their guidelines as well. But well, to my surprise, you are not alone - https://bugzilla.redhat.com/show_bug.cgi?id=2439657 - frankly, if I wasn't the Vim maintainer, I wouldn't type Vi in my case at all :D. Probably number of times I wrote Vi instead of Vim by my own will could be counted on hands, so in my case I could say as user I haven't typed Vi at all in my life, so the situation is reversed for me. Either way, as I mentioned in the original bug, I will provide the aliases and users have been warned of consequences - I hope I will manage to make builds today. *** This bug has been marked as a duplicate of bug 2439657 ***
As a user of Unix-based systems since 1990, I am only tangentially aware that vim = vi on Linux. So...I'm old. I set a shell alias for vi so that it calls vim instead. Thanks!