Open axieax opened 2 years ago
Not sure but it seems https://github.com/lambdalisue/suda.vim/blob/master/autoload/suda.vim#L74 fails somehow...
What happen if you directly call suda#write()
like (note that it will overwrite the content of /etc/foobar
so BE CAREFUL!)
:call suda#write('suda:///etc/foobar')
And
:echo substitute('suda:///etc/foobar', '\v^(suda://)+', '', '')
:call suda#write('suda:///etc/foobar')
No errors, working as expected
:echo substitute('suda:///etc/foobar', '\v^(suda://)+', '', '')
/etc/foobar
Debugging:
plugin/suda.vim
autoload/suda.vim
<afile>
It's quite strange. What happen if you modify the code like
function! suda#write(expr, ...) abort range
echomsg "expr:" . a:expr
echomsg "expand:" . expand(a:expr)
echomsg "path:" . s:strip_prefix(expand(a:expr))
" Original code starts from here
let path = s:strip_prefix(expand(a:expr))
" ...
Sometimes I have issues, sometimes not..
Successful (call nvim /etc/environment
from user home directory, or nvim environment
from /etc):
Fail (call nvim /etc/environment
from root directory):
What about
function! suda#write(expr, ...) abort range
echomsg "expr:" . a:expr
echomsg "expand:" . expand(a:expr)
echomsg "bufname:" . bufname("%")
echomsg "expand:" . expand("%")
echomsg "path:" . s:strip_prefix(expand(a:expr))
" Original code starts from here
let path = s:strip_prefix(expand(a:expr))
" ...
It's quite puzzling... I'm sorry but I've no idea...
Thought this was an issue with my Linux permissions after removing some shada files, but it seems that I can also reproduce this on my Mac. Just wondering if you are able to reproduce this as well?
How to reproduce the issue?
Fail (call nvim /etc/environment from root directory)
Then launch :SudaWrite
Then I could not reproduce it
@axieax I can not reproduce this either. Is your vim config available online?
Hi, yes it's available in my dotconfig repo: https://www.github.com/axieax/dotconfig
Have you tried reproducing this since your migration to lazy.nvim
?
Was struggling to debug this issue for a while, not sure if this is expected behaviour?
SudaWrite /etc/environment from / ->
SudoWrite /etc/environment from /etc -> success