Sometimes when I save a file, I get the following error. I've identified that the 38. plugin is eunuch

"user.py" 198L, 5545C written
Error detected while processing function <SNR>38_W:
line    8:
E382: Cannot write, 'buftype' option is set
Press ENTER or type command to continue

It happens only sometimes, not always. But it sometimes occurs multiple times in a row, when I do 2-3 :w until it stops happening. I haven't really figured out when it is happening.

Here's my ~/.vimrc if that helps

Is it possible to create a copy function which copy file in the same dir with another name ?
Eq. :CopyAs my_file.rb
like: :w %:p:h/my_file.rb

Error detected while processing BufWriteCmd Autocommands for "/etc/fstab":
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

I don't get any prompt for password 🤔
Ubuntu 20.04

Would be better to be explicit, in my opinion.

I can do this if it's fine?

SudoWrite does not work with symlinks:

% echo foo > foo
% sudo chown root foo
% ln -s foo symlink
% vim -c 'norm o2' -c 'SudoWrite' -c q symlink
% cat foo
foo

The expected result would be to have "2" after "foo".

(Initially reported accidentally against chrisbra/SudoEdit.vim#40 (comment))

The implementation of +x and -x do ugo+x and ugo-x respectively, which is not what chmod(1) does when the umask includes any of those bits.

Thoughts on implementation: AFAIK, there's no way to extract the umask in Vim without invoking umask(1), which somewhat undermines the implementation of Chmod in terms of getfperm/setfperm. However, caching the result of invoking the program is probably a reasonable thing to do since there's no way to change the umask either.

Using gvim for Windows 7.4

If using NTFS, cygwin tries to use Access Control Lists from Windows. This
doesn't seem to work very well and resulted in vim-eunuch's auto executable
feature (b:chmod_post) setting only the executable flag and making the file
no longer readable. This is only a problem the first time you chmod a file so
it seems like it's reading the permissions as 000 when applying +x (which is
also what's displayed with ls -l -- most files display no permissions but edit fine in gvim).

It seems like this is a cygwin problem, but it manifested with eunuch so I thought this information could be useful here.

In Rust, there are global attributes written like #![attr] that have to be written before other items in the file. If I happen to write this on the very first line, like I did here, then vim-eunuch decides this must be a script shebang and forces a chmod +x that I don't really want.

Is there a way to prevent this? I'd be perfectly happy to disable this feature for all Rust files.

Hi,

One thing that is very practical with the Rename command is that it works in the containing folder of the file and not in the current working directory. It would be great if vim-eunuch were to provide Copy that would do a copy of the file directly inside the file's containing directory.

Thanks

I found very often (not sure everytime) that, when I change a filename from "Abc-Def.txt" to "abc-def.txt", neither Rename nor Move works. is this expected?
I'm with Vim 8.1 on wsl, if that matters.

Can you please add ":SudoWriteQuit" as equivelant to ":wq"?

I've noticed that SudoWrite would not call BufWritePost, which is not triggered automatically when using BufWriteCmd.

(For reference, I've found an old comment at #36 (comment))

I have used the SudoWrite functionality and have saved me so much time.
Recently i am not sure why i am get the following message when i do the SudoWrite.

Error detected while processing BufWriteCmd Auto commands for "/etc/systemd/logind.conf":
sudo: no tty present and no askpass program specified

Below is my neovim version.
:version
NVIM v0.3.0
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

I have been unpleasantly surprised to find that if I ever create a file with /init.d/ as a component of its full path, I get the contents of /etc/init.d/skeleton in the buffer. I'd like the means to disable this, as I happen to use init.d folders for other purposes here and there. In addition, I already have a means of templating new files if I ever have need of it.

Thanks!

Duplicate a file in same dir is very common, can you consider it?
thanks!

Grep recursively starting from the parent directory of the current file and add the results to the quickfix list.

Hey Tim, firstly thank you for the great plugins!

A common frustration I have is when moving or renaming files from inside vim my ctrlp cache gets outdated. Is it possible to hook in to those functions and add a call to : CtrlPClearCache?

Steps to recreate:

• Open MacVim with vim-eunuch installed. Create a new file with :new. Enter content and save with :w ~/Desktop/foo.txt. As expected, foo.txt is created on the desktop.
• Rename the file with :Rename ~/Desktop/bar.txt. Rather than just renaming the file, it creates a new directory called ~ on the desktop, and puts the file in that, rather than evaluating it as the user's home directory.

This is great plugin, however I'm having problem with understanding how :Find and :Locate works. If I'm at ~, I can open file by it's filename with :Find .vimrc. I can use wildcards. How does :Locate differ? Why searching for views.py doesn't find ~/Python/daGrevis.lv/dagrevis_lv/blog/views.py?

Thanks! :)

Running MacVim on OSX 10.7.4.

As the title states, after I rename a file I am left with a ghost buffer, essentially an old buffer that is empty from the previous file.

Shouldn't it also delete the old buffer?

it seems to me that :Delete only deletes a file.
It would be nice if we can have recursive :Delete to remove a directory and its files

I have this in my .vimrc, appearing before I load eunuch plugin, however the :W command in eunuch over-rides the below command:

" Allow saving a filename with spaces
" :W auto-escapes a filename before writing
command! -bang -nargs=* W :call W(<q-bang>, <q-args>)
function! W(bang, filename)
    :execute "w".a:bang." ". fnameescape(a:filename)
endfunction

Any ideas why this is happening? I can see that the plugin checks for the existence of :W so I'm guessing this check is failing for some reason.

Thanks!

Is there an autocmd fired after a Rename / Delete / Move command? I need to update some vars and my statusbar after executing them

Occasionally when I am editing a file, the whole folder containing the file is moved to another place. This makes the buffer being edited loss its underlying file. Then I will want to move the buffer to the new place.

A simple :saveas! newplace will not work perfectly since the old buffer will still be a listed buffer. Now I come across this very helpful plugin and try to use Move to achieve the goal. However, I found the Move doesn't work either since the source file is already deleted and it ends up with an error msg Failed to rename ..., see definition for command Move.

To reproduce the error, simply enter an empty folder and type vim a and then in vim do :Move b. Since at this time there is no file named a in the file system, the Move is not allowed.

A tried the following solution and it seems to work. It just checks whether the source still exists before perform the real moving. Would you please review the code or give some other suggestions? I can also create the pull request if you feel acceptable. Thank you very much.

command! -bar -nargs=1 -bang -complete=file Move
      \ let s:src = expand('%:p') |
      \ let s:dst = expand(<q-args>) |
      \ if s:fcall('isdirectory', s:dst) || s:dst[-1:-1] =~# '[\\/]' |
      \   let s:dst .= (s:dst[-1:-1] =~# '[\\/]' ? '' : s:separator()) .
      \     fnamemodify(s:src, ':t') |
      \ endif |
      \ call s:mkdir_p(fnamemodify(s:dst, ':h')) |
      \ let s:dst = substitute(s:fcall('simplify', s:dst), '^\.\'.s:separator(), '', '') |
      \ if <bang>1 && s:fcall('filereadable', s:dst) |
      \   exe 'keepalt saveas '.s:fnameescape(s:dst) |
      \   if !s:fcall('filereadable', s:src) |
      \     execute 'bwipe '.s:fnameescape(s:src) |
      \   endif |
      \ elseif s:fcall('filereadable', s:src) && EunuchRename(s:src, s:dst) |
      \   echoerr 'Failed to rename "'.s:src.'" to "'.s:dst.'"' |
      \ else |
      \   setlocal modified |
      \   exe 'keepalt saveas! '.s:fnameescape(s:dst) |
      \   if s:src !=# expand('%:p') |
      \     execute 'bwipe '.s:fnameescape(s:src) |
      \   endif |
      \   filetype detect |
      \ endif |
      \ unlet s:src |
      \ unlet s:dst |
      \ filetype detect

This plugin a super handy, but is missing one of the most common things I have to do in vim - write a new file to a new folder. It would be nice to have a :wf command that could write a new file into a new folder structure that could be created recursively. What do you think?

When I run :Chmod with any arguments I've tried such as +x or 0777 I get this error:

chmod: --: No such file or directory

This obviously comes from this line but I'm not sure why it's there now so I must be missing something.

I'm using NeoVim and know :SudoWrite cannot work by default settings. So I searched issues and found a workaround in #56 (comment) .

I tried this workaround but still it did not work. So I invested the source and found here.

@tpope says this line detects the env is NeoVim in local ( #45 (comment) ). But is $SECURITYSESSIONID needed to check? At least in my env (macOS Mojave 10.14.6), $SECURITYSESSIONID is always empty even in local.

For a stopgap measure, I wrote below in init.vim and successfully :SudoWrite works! thx @TSFoster !

if $SECURITYSESSIONID == ''
  let $SECURITYSESSIONID = 'dummy'
endif
let $SUDO_ASKPASS = '/path/to/macos-askpass'

Pretty easy fix, just tag commit 16f6434.

Given I'm in a file called "SVM.py", and I try :Move svm.py, it will just do a no-op; it won't create a new file, and won't change the buffer name. Is it something Vim-related?

I am experimenting with setting Vim's 'directory' setting, to not clutter directories with swap files.

When using :Move, a swap file warning appears:

Swap file "/home/user/tmp/vim/swapfiles/foo.swp" exists, overwrite anyway?

Since this is the expected behavior / the same/old file, there should be no warning.

Calling :SudoWrite on a buffer for a file that has been removed is reported as success

Steps to reproduce:

• mkdir /tmp/ve/
• touch /tmp/ve/file.txt
• vim /tmp/ve/file.txt
• in terminal: rm -rf /tmp/ve/
• :SudoWrite

The buffer is now marked as nomodified, but the file does not actually exist on disk.

However, if you use !sudo tee % instead of :SudoWrite, it properly reports the error:
E211: File "/tmp/ve/file.txt" no longer available

I have tested vim-eunuch to be working on Linux with the same .vimrc fie, but I have trouble getting it to work on Windows. I have changed from:

fnamemodify(bufname(<q-args>),':p')

to

bufname(expand('%')) 

on line 17, but it does not still work with delete().
When I run :call delete(bufname(expand('%'))) manually, it works. Do you have any idea?

Steps to reproduce:
vimrc:

colorscheme guimiromod
execute 'set runtimepath^=' . expand('~/.vim/bundle/vim-eunuch')
syntax on

$ vim somefile.py # somefile.py doesn't exist yet

In somefile.py, type something that would get syntax highlighted, e.g. #!/usr/bin/python, then :w<CR>, and syntax gets turned off. It can be turned back on with :syntax on<CR>, but then for some reason this turns off the basic colors I have configured for my statusline.

Line 174 of eunuch.vim seems to be the culprit, commenting it fixes this bug:
autocmd BufNewFile * let b:brand_new_file = 1

I haven't read through enough of the plugin to understand what the point of that variable is.

Modification of user environment in sudoedit was considered a bug and fixed in the 1.8.13 release.
https://bugzilla.sudo.ws/show_bug.cgi?id=688

I'm not sure it's possible to find out if vim is executed by sudoedit anymore. My current workaround is to create a shell function sudoedit() { SUDO_COMMAND="sudoedit $1" command sudoedit "$1" }

I get this error when I do SudoWrite.

See the attached

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Apr 10 2018 23:54:40)
on CentOS Linux release 7.5.1804 (Core)

Hey Tim

First of all, thank you for more this plugin, it is so useful!

Second, I would like to propose a minor enhancement.

:Rename %<tab> "to exapand the file path

This is very useful in case you need just to fix a typo, or add/remove a folder in the path. As for the moment the % wont expand.

Cheers!

I get this weird behavior: After typing the password and pressing Enter, the shell seems to be stuck and I have to press a few times in order to stop it, Afterwards the file is not saved and I don't gain sudo permissions. I tried change the function! s:SudoWriteCmd() and it worked, but it seems weird to make a pull request about it because I don't know what doesn't work in the original function.
my version for the function is as follow:

function! s:SudoWriteCmd() abort
  execute (has('gui_running') ? '' : 'silent') 'write !sudo tee "%"'
  let &modified = v:shell_error
endfunction

And your version for the execute command is:

  execute (has('gui_running') ? '' : 'silent') 'write !env SUDO_EDITOR=tee VISUAL=tee sudo -e "%" >/dev/null'

What is the purpose of > /dev/null? Why wouldn't you keep it simple like in my version?

Hello, If I open a new tab with a new terminal, then If I input command :Wall, neovim will be in insert mode.

Hello, :SudoEdit doesn't deal well with files which the user has no permission of listing/reading.

sudo -e ./protected_folder/protected_file.yaml opens the file with the correct filetype set.

:SudoEdit loads the file but filetype is set as nothing.

As the title states, :Remove appears to delete the buffer, but does not actually remove the file.

There seems to be no other errors either, or even anything spit out in :messages

I somehow formed the impression that eunuch :Renames etc. made the corresponding changes to a Git repo. But on my new machine it isn't as I think I remember. Is there a tpope plugin I'm missing that makes this so? If there is, then this is a documentation request that a note be added about how to enable that coolness.

Thanks for great tools.

Hi! I was testing Cfind command and I notice that after I use it, grepprg value was not restoring for his previous value. I set a different variable name in s:Grep and I was able to get it work. I think that was a conflit between the function variable name and the local option name beeing the same. I'm just speculating here, because I set rg for grepprg. Big fan of your work! The Pope of Vim! :)

I'm sure you have thought about this @tpope. Is there any reason not to have file completion on :Remove ?

When using :Remove on a buffer in arglist, also remove the corresponding file from the arglist.
(Renaming with :Move works as expected.)

Steps to recreate:

• Create a new file with :new, and enter some contents. Save with :w, using a .txt extension.
• Use :Move to rename the file to another filetype (e.g. .mkd for markdown).

Result:

• The filetype used by vim for syntax highlighting etc. doesn't change.

I assume that the appropriate fix for this would be to fire a BufRead or BufNewFile autocmd?

If I get a moment, I may look at fixing this myself.

It seems that the skeleton isn't there anymore, now the template is buried in a man page, but it is smaller:

#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:          atd
# Required-Start:    $syslog $time $remote_fs
# Required-Stop:     $syslog $time $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: run at jobs
# Description:       Debian init script to start the daemon running at jobs.
### END INIT INFO
DAEMON=/usr/sbin/atd

I'm not sure how to integrate that (it is only available on debian derivatives that still use init.d).

I've been using sudowrite for system configuration in conjunction with some VCS. I'd like to be able to cue "smarter" behavior for this scenario, in this case adjust the behavior of the VCS calls to reflect a need for privileged invocation.

This seems like other commands might want to know this as well.

(somewhat related to #55, but simpler)

If you start a new file with :e new_file, then add some content but don't save it, :Rename better_name won't work.

I think it should just rename the buffer and ignore the missing file.

I know there's :file for that, but it doesn't work relative to the current file's containing directory.

I would like to not have the :W command (which I accidentally use sometimes instead of :w).

Can you make it optional via a variable? Would you accept a pull request for that?

For now I have added delcommand W to ~/.vim/after/plugin/after.vim.

This may be outside of the scope of the project, but I would certainly find it extremely useful, as manually executing :!mkdir in Vim is tedious. This would be particularly useful for the :Rename! command since it operates relative to the current file, and :!mkdir does not. Applying this functionality only if the bang is passed is consistent with the notion of "forcefulness". Thoughts?