I am developing a command line application that uses VIM to edit an existing file - think visudo or crontab -e

When I launch VIM, I'm passing it the path of an existing file. I want the user to be able to modify and save the file (e.g. :w or ZZ) but I do not want the user to have the ability to save the file with another name, e.g. :w new-name.txt

Is there any command line option that I can pass to VIM to disable or prevent saving to a new or other file?

  • Like parental controls in Vim? :) You talking about a hardened solution that is difficult to subvert? Or are you just looking for something that puts up light resistance but will not stop someone who is determined to write a new file?
    – B Layer
    Feb 6, 2018 at 10:31

2 Answers 2


I don't believe it's possible to completely prevent the user from doing this.

However, you could prevent the user from doing it inadvertently via the use of autocommands. Here's a rough proof of concept that ignores the new file name when the user attempts :w newname.txt:

augroup MySave
autocmd BufWriteCmd * :w % | set nomodified
augroup END

However, note that there are many ways that a user can save text to a file in Vim. e.g. If you also want to catch :saveas, you're going to also need to look into the BufFilePre/BufFilePost autocommands; if you want to prevent the user writing ranges of the file, you'll also need to set up something for FileWriteCmd etc.

You might also want to start Vim with the -Z argument. See :help -Z.

See :help autocmd.txt for more details, in particular, :help Cmd-event.

A sufficiently knowledgeable user could simply remove these autocommands, (and even if they couldn't, they could just copy the text to the clipboard!) so this will only be a speedbump for a someone determined to save the text elsewhere.

  • Thank you for the excellent info! I will certainly give this a try. Hoop jumping is fine but I'm not looking to go to heroic lengths. I'm not concerned with content stealing; I'm more looking to protect against "quick finger syndrome" where one might accidentally type :w- or :w=
    – LiamF
    Feb 7, 2018 at 21:29

As suggested by the answer from @Rich, you'll have to jump through lots of hoops to make this work well in Vim. Depending on how secure you want it to be, you might be better off looking to the hosting operating system (ACL, file system permissions, chroot/jails etc.) For instance, you might set up a user with very tight restrictions on what they are permitted to do (e.g. they aren't allowed to create files on disk) and run vim as that user. This way you'll have the assurance of being backed by a proven authorization solution.

However you do it take note of :h -Z. This puts Vim in restricted mode which blocks commands that use an external shell...the first thing someone serious about getting around the restrictions would look at. - Aha, I just noticed that @Rich already mentioned this. Well, it's a good idea! :)

Any way you slice it I don't see this being an easy problem to solve.

  • A restricted user may be an option I should consider. It would be more convenient if I could create some kind of shell sandbox over which I would have such control w/o the need for a whole new user or group. This has definitely given me more to think about; thanks! And answers by you and @Rich inadvertently solved my sister question, Disable Shell Escapes Thanks for that!
    – LiamF
    Feb 7, 2018 at 21:35
  • @LiamF You bet. Hope you figure it all out.
    – B Layer
    Feb 8, 2018 at 0:36
  • 1
    @LiamF BTW, you mentioned sandboxing...if that's the kind of direction you wanted to go and are using *nix there is native support for process isolation/restriction, applicable to existing users/groups, via chroot and its siblings as well as the many offshoots from them. (Modern containerization technologies like cgroups (think Docker) have evolved from these features.) Getting a little far afield here but figured I'd throw it out there. en.wikipedia.org/wiki/Chroot
    – B Layer
    Feb 8, 2018 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.