Loading ...
Sorry, an error occurred while loading the content.

netrw copy fails, trouble installing v.147

Expand Messages
  • Paul
    I took a jab at a problem that experienced with netrw 140 for gvim on Windows 7. Within the past year some time, I dabbled in some of the more advanced
    Message 1 of 7 , Apr 1, 2013
    • 0 Attachment
      I took a jab at a problem that experienced with netrw 140 for gvim on
      Windows 7. Within the past year some time, I dabbled in some of the
      more advanced features netrw, namely copy marked files to a marked
      target directory. (yes, I've been posting from different gmails
      depending on whether I'm at work machine). While I can mark the files
      and the target directory, "mc" doesn't seem to cause the files to be
      copied. I found this to be the case on two different computers (both
      Windows 7), one on which I had admin privileges and on which I did the
      troubleshooting. On that computer, netrw 140 works fine for gvim on
      Cygwin's Xwin.

      I know it's nothing to do with my vimrc (where I do some abominations
      to be able to shell out to bash) because I used the vim73/
      vimrc_example.vim that came with the installation. I also found this
      topic at http://groups.google.com/forum/#!topic/vim_use/BVcfJHdD6x8,
      so I checked that g:netrw_localcopycmd was already set to 'copy'. I
      additionally let g:netrw_local_copycmd='copy', but that didn't work.

      I did the following to capture any messages in register "a" and Put it
      into a New file:

      :redir @a
      mc
      :redir END
      :new
      "aP

      The message is verbose, but identical for both Windows & Xwin
      versions, with the exception of the double-dotted "y" character in the
      "Pattern not found" messages. I manually folded the longer lines to
      try and minimize confusion:

      22 fewer lines
      <cygwin\home\LoalAdmin\tmp" --No lines in buffer--
      Error detected while processing function <SNR>24_NetrwMarkFileCopy
      ..<SNR>24_LocalBrowseShellCmdRefresh..<SNR>24_NetrwRefresh
      ..netrw#LocalBrowseCheck..<SNR>24_NetrwBrowse
      ..<SNR>24_BrowserMaps:
      line 102:
      E121: Undefined variable: s:didstarstar
      Error detected while processing function <SNR>24_NetrwMarkFileCopy
      ..<SNR>24_LocalBrowseShellCmdRefresh..<SNR>24_NetrwRefresh
      ..netrw#LocalBrowseCheck..<SNR>24_NetrwBrowse
      ..<SNR>24_BrowserMaps:
      line 102:
      E15: Invalid expression: s:didstarstar || !mapcheck("<s-down>","n")
      Error detected while processing function <SNR>24_NetrwMarkFileCopy
      ..<SNR>24_LocalBrowseShellCmdRefresh..<SNR>24_NetrwRefresh
      ..netrw#LocalBrowseCheck..<SNR>24_NetrwBrowse
      ..<SNR>24_BrowserMaps:
      line 106:
      E121: Undefined variable: s:didstarstar
      Error detected while processing function <SNR>24_NetrwMarkFileCopy
      ..<SNR>24_LocalBrowseShellCmdRefresh..<SNR>24_NetrwRefresh
      ..netrw#LocalBrowseCheck..<SNR>24_NetrwBrowse
      ..<SNR>24_BrowserMaps:
      line 106:
      E15: Invalid expression: s:didstarstar || !mapcheck("<s-up>","n")
      Error detected while processing function <SNR>24_NetrwMarkFileCopy
      ..<SNR>24_LocalBrowseShellCmdRefresh..<SNR>24_NetrwRefresh
      ..netrw#LocalBrowseCheck..<SNR>24_NetrwBrowse
      ..<SNR>24_PerformListing..<SNR>24_NetrwBookHistHandler
      ..<SNR>24_NetrwBookmarkMenu:
      line 10:
      E329: No menu "Bookmarks"
      Error detected while processing function <SNR>24_NetrwMarkFileCopy
      ..<SNR>24_LocalBrowseShellCmdRefresh..<SNR>24_NetrwRefresh
      ..netrw#LocalBrowseCheck..<SNR>24_NetrwBrowse
      ..<SNR>24_PerformListing..<SNR>24_NetrwBookHistHandler
      ..<SNR>24_NetrwBookmarkMenu:
      line 11:
      E329: No menu "Bookmark Delete"
      E486: Pattern not found: ^$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.h$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.c$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.cpp$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.o$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.obj$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.info$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: \.bak$
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/
      E486: Pattern not found: ^\d\{3}ÿ\d\{3}\/

      Because of the identicalness, I assumed that these messages didn't
      contain the clue to the problem.

      From a previous posting on this forum I was advised to try netrw 147,
      which I un-vimballed into "c:/Program Files (x86)/Vim/vimfiles". No
      need to set g:vimball_home because the above directory was the first
      valid directory in runtimepath. I confirmed that files unloaded into
      their subdirectories and that it superceded the corresponding files in
      "c:/Program Files (x86)/Vim/vim73". In fact, I later also un-
      vimballed them into "c:/Program Files (x86)/Vim/vim73". In both
      cases, it seemed that netrw failed to run. Doing ":e ." yields the
      message

      "." is a directory

      and the buffer appears exactly as an empty file would. Redirecting
      messages to @a captures these messages:

      "." is a directory
      Error detected while processing function <SNR>14_LocalBrowse:
      line 14:
      E117: Unknown function: netrw#LocalBrowseCheck

      I confirmed that all files and subdirectories were readable and
      executable/accessible by all users and that there was no funny
      business with Windows 7 virtualization i.e. the following directory
      was completely empty of visible & hidden files:

      c:/Users/LoalAdmin/AppData/Local/VirtualStore

      I've been troubleshooting this problem a number of hours, and
      somewhere in my rummaging about, I recall getting an warning message
      that netrw 147 required vim 7.3.XXX, where XXX was a decimal number in
      the 100-199 range. I don't recall how I got it, but I remember
      wondering whether XXX corresponded to the patch number. If so, that
      might explain it because the gvim for Xwin was around patch 172 (which
      was higher than XXX) whereas Windows gvim only "Included patches:
      1-46". Is this correct? My Windows version is:

      VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02)
      MS-Windows 32-bit GUI version with OLE support
      Included patches: 1-46
      Compiled by Bram@KIBAALE
      Big version with GUI. Features included (+) or not (-):
      +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
      +cindent
      +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
      +comments
      +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui
      +diff
      +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
      +farsi
      +file_in_path +find_in_path +float +folding -footer +gettext/dyn -
      hangul_input
      +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall
      +linebreak
      +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
      +mouse
      +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg
      +ole
      -osfiletype +path_extra +perl/dyn +persistent_undo -postscript
      +printer
      -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/
      dyn
      +scrollbind +signs +smartindent -sniff +startuptime +statusline -
      sun_workshop
      +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent
      -termresponse +textobjects +title +toolbar +user_commands +vertsplit
      +virtualedit +visual +visualextra +viminfo +vreplace +wildignore
      +wildmenu
      +windows +writebackup -xfontset -xim -xterm_save +xpm_w32
      system vimrc file: "$VIM\vimrc"
      user vimrc file: "$HOME\_vimrc"
      2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
      2nd user exrc file: "$VIM\_exrc"
      system gvimrc file: "$VIM\gvimrc"
      user gvimrc file: "$HOME\_gvimrc"
      2nd user gvimrc file: "$VIM\_gvimrc"
      system menu file: "$VIMRUNTIME\menu.vim"
      Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -
      DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 -
      D_WIN32_WINNT=0x0400 /Fo.\ObjGOLYHTR/ /Ox /GL -DNDEBUG /Zl /MT -
      DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -
      DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -
      DDYNAMIC_TCL_DLL=\"tcl83.dll\" -DDYNAMIC_TCL_VER=\"8.3\" -DFEAT_PYTHON
      -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -
      DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python31.dll\" -DFEAT_PERL -
      DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl512.dll\" -DFEAT_RUBY -
      DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\"msvcrt-
      ruby191.dll\" -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi
      Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS
      oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib
      comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib
      version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /
      machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /
      nodefaultlib:python27.lib /nodefaultlib:python31.lib e:\tcl\lib
      \tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib /PDB:gvim.pdb -debug

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Charles Campbell
      ... [snip] I m not seeing that problem, but the latest netrw insures that s:didstarstar exists. Please download a copy from my website:
      Message 2 of 7 , Apr 2, 2013
      • 0 Attachment
        Paul wrote:
        > I took a jab at a problem that experienced with netrw 140 for gvim on
        > Windows 7. Within the past year some time, I dabbled in some of the
        > more advanced features netrw, namely copy marked files to a marked
        > target directory. (yes, I've been posting from different gmails
        > depending on whether I'm at work machine). While I can mark the files
        > and the target directory, "mc" doesn't seem to cause the files to be
        > copied. I found this to be the case on two different computers (both
        > Windows 7), one on which I had admin privileges and on which I did the
        > troubleshooting. On that computer, netrw 140 works fine for gvim on
        > Cygwin's Xwin.
        >
        [snip]

        I'm not seeing that problem, but the latest netrw insures that
        s:didstarstar exists. Please download a copy from my website:

        http://www.drchip.org/astronaut/vim/index.html#NETRW
        >
        > >From a previous posting on this forum I was advised to try netrw 147,
        > which I un-vimballed into "c:/Program Files (x86)/Vim/vimfiles". No
        > need to set g:vimball_home because the above directory was the first
        > valid directory in runtimepath.
        [snip]
        Hmm, that looks problematic, because it looks like where vim's system
        files appear. I'll have to take a look at vimball and make sure that
        its not unpacking into system directories automatically.
        What does :echo &rtp show?
        > I've been troubleshooting this problem a number of hours, and
        > somewhere in my rummaging about, I recall getting an warning message
        > that netrw 147 required vim 7.3.XXX, where XXX was a decimal number in
        > the 100-199 range.
        [snip]

        I confirm: as the message said, the latest netrw requires 7.3.465, which
        is referring to vim's patch level.

        Regards,
        C Campbell

        --
        --
        You received this message from the "vim_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Tony Mechelynck
        ... Dear Dr. Chip: Vim s system files should be in c:/Program Files (x86)/Vim/vim73/ aka $VIMRUNTIME -- c:/Program Files (x86)/Vim/vimfiles/ is $VIM/vimfiles/
        Message 3 of 7 , Apr 2, 2013
        • 0 Attachment
          On 02/04/13 18:23, Charles Campbell wrote:
          > Paul wrote:
          >> I took a jab at a problem that experienced with netrw 140 for gvim on
          >> Windows 7. Within the past year some time, I dabbled in some of the
          >> more advanced features netrw, namely copy marked files to a marked
          >> target directory. (yes, I've been posting from different gmails
          >> depending on whether I'm at work machine). While I can mark the files
          >> and the target directory, "mc" doesn't seem to cause the files to be
          >> copied. I found this to be the case on two different computers (both
          >> Windows 7), one on which I had admin privileges and on which I did the
          >> troubleshooting. On that computer, netrw 140 works fine for gvim on
          >> Cygwin's Xwin.
          >>
          > [snip]
          >
          > I'm not seeing that problem, but the latest netrw insures that
          > s:didstarstar exists. Please download a copy from my website:
          >
          > http://www.drchip.org/astronaut/vim/index.html#NETRW
          >>
          >> >From a previous posting on this forum I was advised to try netrw 147,
          >> which I un-vimballed into "c:/Program Files (x86)/Vim/vimfiles". No
          >> need to set g:vimball_home because the above directory was the first
          >> valid directory in runtimepath.
          > [snip]
          > Hmm, that looks problematic, because it looks like where vim's system
          > files appear. I'll have to take a look at vimball and make sure that
          > its not unpacking into system directories automatically.
          > What does :echo &rtp show?
          >> I've been troubleshooting this problem a number of hours, and
          >> somewhere in my rummaging about, I recall getting an warning message
          >> that netrw 147 required vim 7.3.XXX, where XXX was a decimal number in
          >> the 100-199 range.
          > [snip]
          >
          > I confirm: as the message said, the latest netrw requires 7.3.465, which
          > is referring to vim's patch level.
          >
          > Regards,
          > C Campbell
          >

          Dear Dr. Chip:

          Vim's system files should be in c:/Program Files (x86)/Vim/vim73/ aka
          $VIMRUNTIME -- c:/Program Files (x86)/Vim/vimfiles/ is $VIM/vimfiles/
          which is where system-wide Vim "full-fledged script" customizations are
          kept.


          Best regards,
          Tony.
          --
          JOHN CLEESE PLAYED: SECOND SOLDIER WITH A KEEN INTEREST IN BIRDS, LARGE MAN
          WITH DEAD BODY, BLACK KNIGHT, MR NEWT (A VILLAGE
          BLACKSMITH INTERESTED IN BURNING WITCHES), A QUITE
          EXTRAORDINARILY RUDE FRENCHMAN, TIM THE WIZARD, SIR
          LAUNCELOT
          "Monty Python and the Holy Grail" PYTHON (MONTY)
          PICTURES LTD

          --
          --
          You received this message from the "vim_use" 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_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Charles Campbell
          ... Thank you, Tony -- I was going to check on that later when I have access to a Windows box. Regards, C Campbell -- -- You received this message from the
          Message 4 of 7 , Apr 2, 2013
          • 0 Attachment
            Tony Mechelynck wrote:
            > Dear Dr. Chip:
            >
            > Vim's system files should be in c:/Program Files (x86)/Vim/vim73/ aka
            > $VIMRUNTIME -- c:/Program Files (x86)/Vim/vimfiles/ is $VIM/vimfiles/
            > which is where system-wide Vim "full-fledged script" customizations are
            > kept.
            >
            Thank you, Tony -- I was going to check on that later when I have access
            to a Windows box.

            Regards,
            C Campbell

            --
            --
            You received this message from the "vim_use" 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_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Paul
            On Apr 2, 2:15 pm, Charles Campbell ... Tony, Charles, you seem to be the gray beards here! Thanks for the clarification. I did
            Message 5 of 7 , Apr 2, 2013
            • 0 Attachment
              On Apr 2, 2:15 pm, Charles Campbell <Charles.E.Campb...@...>
              wrote:
              > Tony Mechelynck wrote:
              >> Vim's system files should be in c:/Program Files (x86)/Vim/vim73/ aka
              >> $VIMRUNTIME -- c:/Program Files (x86)/Vim/vimfiles/ is $VIM/vimfiles/
              >> which is where system-wide Vim "full-fledged script" customizations are
              >> kept.
              >
              > Thank you, Tony -- I was going to check on that later when I have access
              > to a Windows box.

              Tony, Charles, you seem to be the gray beards here!

              Thanks for the clarification. I did indeed try unpacking netrw v.147
              to both locations and confirmed that they were in each. I also
              confirmed that all files & directories were read/execute/accessible to
              all and that they were not user-specific virtual instantiations (a
              Windows 7 feature). In both cases, I got the same behaviour i.e. when
              I edited a directory, I got what appeared to be an empty file.

              On a separate matter, even if I got netrw 147 working on the computer
              for which I have admin privileges, it would not be a solution for the
              copying of marked files by the Windows-based gvim on the locked down
              computer (which is where I will be spending most of my time). There
              are barriers to getting anything installed there. Is there another
              avenue I can pursue for that scenario?

              --
              --
              You received this message from the "vim_use" 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_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Paul
              ... OK, that was confusing. What I mean to say was that if netrw 147 solves the problem on the unlocked-down machine, it requires an upgrade of gvim itself.
              Message 6 of 7 , Apr 2, 2013
              • 0 Attachment
                On Apr 2, 5:30 pm, Paul wrote:
                >On Apr 2, 2:15 pm, Charles Campbell wrote:
                >> Tony Mechelynck wrote:
                >>> Vim's system files should be in c:/Program Files (x86)/Vim/vim73/
                >>> aka $VIMRUNTIME -- c:/Program Files (x86)/Vim/vimfiles/ is
                >>> $VIM/vimfiles/ which is where system-wide Vim "full-fledged
                >>> script" customizations are kept.
                >>
                >> Thank you, Tony -- I was going to check on that later when I have
                >> access to a Windows box.
                >
                > Thanks for the clarification. I did indeed try unpacking netrw
                > v.147 to both locations and confirmed that they were in each. I
                > also confirmed that all files & directories were
                > read/execute/accessible to all and that they were not user-specific
                > virtual instantiations (a Windows 7 feature). In both cases, I got
                > the same behaviour i.e. when I edited a directory, I got what
                > appeared to be an empty file.
                >
                > On a separate matter, even if I got netrw 147 working on the
                > computer for which I have admin privileges, it would not be a
                > solution for the copying of marked files by the Windows-based gvim
                > on the locked down computer (which is where I will be spending most
                > of my time). There are barriers to getting anything installed
                > there. Is there another avenue I can pursue for that scenario?

                OK, that was confusing. What I mean to say was that if netrw 147
                solves the problem on the unlocked-down machine, it requires an
                upgrade of gvim itself. For the locked down machine, such an upgrade
                would not be feasible in the near and medium term. I was wondering if
                there was anything further I could try with the existing Windows-based
                gvim, version 7.3 with patches 1-46 (version info in my original
                post).

                Thanks.

                --
                --
                You received this message from the "vim_use" 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_use" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Paul
                Charles, I seem to have skipped over some of your comments and questions. Sorry about that. On Apr 2, 12:23 pm, Charles Campbell
                Message 7 of 7 , Apr 3, 2013
                • 0 Attachment
                  Charles, I seem to have skipped over some of your comments and
                  questions. Sorry about that.

                  On Apr 2, 12:23 pm, Charles Campbell <Charles.E.Campb...@...>
                  wrote:
                  >Paul wrote:
                  >>> From a previous posting on this forum I was advised to try netrw
                  >>> 147, which I un-vimballed into "c:/Program Files
                  >>> (x86)/Vim/vimfiles". No need to set g:vimball_home because the
                  >>> above directory was the first valid directory in runtimepath.
                  >
                  > Hmm, that looks problematic, because it looks like where vim's
                  > system files appear. I'll have to take a look at vimball and make
                  > sure that its not unpacking into system directories automatically.
                  >
                  > What does :echo &rtp show?

                  C:/vimfiles,C:\Program Files (x86)\Vim/vimfiles,C:\Program Files
                  (x86)\Vim\vim73,C:\Program Files (x86)\Vim/vimfiles/after,C:/vimfiles/
                  after

                  I un-vimballed netrw 147 into both the 2nd & 3rd directories.

                  >> I've been troubleshooting this problem a number of hours, and
                  >> somewhere in my rummaging about, I recall getting an warning
                  >> message that netrw 147 required vim 7.3.XXX, where XXX was a
                  >> decimal number in the 100-199 range.
                  >
                  > I confirm: as the message said, the latest netrw requires 7.3.465,
                  > which is referring to vim's patch level.

                  OK, that means that I have to upgrade gvim for Windows, which means
                  it's not a solution for the locked down computer. I don't suppose
                  there is anything further I could try to troubleshoot the "mc" in
                  netrw 140?

                  --
                  --
                  You received this message from the "vim_use" 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_use" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                Your message has been successfully submitted and would be delivered to recipients shortly.