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()"). It used to be that the COMSPEC environment variable pointed to the DOS/Windows system command interpreter (originally C:\COMMAND.COM, but I suppose it was changed when COMMAND.COM became deprecated. If it is not defined anymore, or if its value is not a usable "Dos box" program, I expect problems in non-Vim-related applications too. So is it defined on your system? If not, find out the name and path of your command interpreter (C:\CMD.EXE maybe?) and try setting $COMSPEC to that value near the top of your _vimrc. The problem is that FAT-based disk filesystems don't define an executable bit, so executable() is not as straightforward there as on most filesystems used by Unix-like OSes, where the appropriate "x" bit in drwxrwxrwx can simply be tested for on or off. What is described under ":help executable()" under "On MS-DOS and MS-Windows" (twice; and sic) sounds reasonable to me though. Or does your Dos Box program not have an extension in the set [ "exe", "com", "bat", "cmd" ] ? Best regards, Tony. -- -- 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.
