mattn wrote: > On Wednesday, November 9, 2016 at 10:53:08 PM UTC+9, Tony Mechelynck wrote: >> On Wed, Nov 9, 2016 at 2:12 AM, mattn <[email protected]> wrote: >>> On Wednesday, November 9, 2016 at 3:58:03 AM UTC+9, DrChip wrote: >>>> Cesar Romani wrote: >>>> Netrw actually doesn't check that expand("$COMSPEC") is execuable before >>>> setting up g:netrw_localcopycmd; instead, it uses that if netrw reports >>>> has("win32") || has("win95") || has("win64") || has("win16") is true and >>>> that g:netrw_cygwin is false. >>>> >>>> So, what should one use instead of expand("$COMSPEC"), and how do I >>>> detect that condition? The expand("$COMSPEC") stuff used to work, so >>>> presumably Windows has changed things (and I'm primarily a Linux user). >>>> >>>> Alternatively, one may provide substitutes for the various commands: >>>> (ie. the command to be run as a string) >>>> >>>> g:netrw_localcopycmd >>>> g:netrw_localcopydircmd >>>> g:netrw_localmkdir >>>> g:netrw_localmovecmd >>>> g:netrw_localrmdir >>>> >>>> Please let me know what those commands are. >>> Not different from autoload/netrw.vim is defined for. Problem is a checking >>> with executable(). >>> >>> BTW, I want to hear the answer from you about permiting to modify your >>> codes to us. >>> >>> I'm thinking that current development speed is so wrong. This is NOT only >>> things about netrw. Many authors of third-party plugin/files are already >>> spoiled to keep development. And they doesn't know how many problems is >>> remaining on vim8. >>> Dr Chip, for example, have you seen this? >>> >>> https://github.com/vim/vim/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20netrw >>> >>> Maybe, the problems occuring on users are not same that you know. I'm >>> guessing that this is a reason that netvim is started. We can implement >>> timer APIs, We can implement job APIs, We can implment channel APIs. But >>> that was slowly to start. >>> >>> We need contribute from users. And I'm thinking that we should be possible >>> to modify bundled files directly. If those are personaly plugin isolated >>> from vim, it won't be a problem. But those are bundled as vim runtime >>> files. So I hope that vim-dev should manage latest version. My opinion may >>> not be a correct answer for this problem. So if you have opinion about >>> this, please let me known. >>> >>> I'm very sorry to trouble you about my rude, but waiting your answer. >>> >>> Thanks. >>> - mattn >> On the Windows system where you noticed this problem, is the PATHEXT >> environment variable set? If it is, try clearing it near the top of >> your _vimrc (see ":help executable()"). > No, problem is simple. > > :echo executable("cmd.exe") > 1 > > :echo executable("cmd.exe /c copy") > 0 > > The command should be specified as filename not with arguments. > > I don't have a windows box handy at the moment to test v162c of netrw out; however, I've split the options off from the commands. The executable() test was supposed to be bypassed if the command was $COMSPEC followed by a space or tab; apparently it was being invoked anyway. You can get v162c from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW .
Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
