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

Apparent bug with file upward-search on Windows

Expand Messages
  • Brett Stahlman
    Hello, I ve read the section on upward search (:help file-searching), and believe I understand how it s supposed to work. The example in the help works the way
    Message 1 of 5 , Jun 8, 2014
    • 0 Attachment
      Hello,
      I've read the section on upward search (:help file-searching), and believe I
      understand how it's supposed to work. The example in the help works the way I
      expect on Linux, but not on Windows.

      Specifically, I created the following set of files and directories to match
      the example from the help:

      C:/Users/stahlmanb/tmp/u/user_x/work/release/test.c
      C:/Users/stahlmanb/tmp/u/user_x/include/test.h

      Note: To make things work on Windows, I've simply replaced Linux `/' with the
      following Windows path: C:/Users/stahlmanb/tmp/

      Then, within Vim...
      cd C:/Users/stahlmanb/tmp/u/user_x/work/release
      e test.c
      set path=include;C:/Users/stahlmanb/tmp/u/user_x

      Hitting gf with the cursor positioned on test.h (inside test.c) produces...
      E447: Can't find file "test.h" in path

      I recreated the same test on Linux, replacing...
      C:/Users/stahlmanb/tmp/
      ...with...
      /home/stahlman/tmp/
      ...and everything worked as expected: test.h was found in the
      /home/stahlman/tmp/u/user_x/include directory.

      Is there something I've missed that could explain the discrepancy, or is this
      a bug?

      Thanks,
      Brett Stahlman

      --
      --
      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/d/optout.
    • Tony Mechelynck
      ... In the path option, a single dot means the same directory as the file and an empty item (two commas after each other) mean the current directory. Both
      Message 2 of 5 , Jun 8, 2014
      • 0 Attachment
        On 08/06/14 21:16, Brett Stahlman wrote:
        > Hello,
        > I've read the section on upward search (:help file-searching), and believe I
        > understand how it's supposed to work. The example in the help works the way I
        > expect on Linux, but not on Windows.
        >
        > Specifically, I created the following set of files and directories to match
        > the example from the help:
        >
        > C:/Users/stahlmanb/tmp/u/user_x/work/release/test.c
        > C:/Users/stahlmanb/tmp/u/user_x/include/test.h
        >
        > Note: To make things work on Windows, I've simply replaced Linux `/' with the
        > following Windows path: C:/Users/stahlmanb/tmp/
        >
        > Then, within Vim...
        > cd C:/Users/stahlmanb/tmp/u/user_x/work/release
        > e test.c
        > set path=include;C:/Users/stahlmanb/tmp/u/user_x
        >
        > Hitting gf with the cursor positioned on test.h (inside test.c) produces...
        > E447: Can't find file "test.h" in path
        >
        > I recreated the same test on Linux, replacing...
        > C:/Users/stahlmanb/tmp/
        > ...with...
        > /home/stahlman/tmp/
        > ...and everything worked as expected: test.h was found in the
        > /home/stahlman/tmp/u/user_x/include directory.
        >
        > Is there something I've missed that could explain the discrepancy, or is this
        > a bug?
        >
        > Thanks,
        > Brett Stahlman
        >

        In the 'path' option, a single dot means "the same directory as the
        file" and an empty item (two commas after each other) mean the current
        directory. Both are included in the default value. Also, that option is
        a _comma_-separated list, not a _semicolon_-separated list. See the
        example at the very end of the ":help 'path'" section, immediately
        before ":help 'preserveindent'".


        Berst regards,
        Tony.
        --
        There once was a fellow named Sweeney
        Who spilled gin all over his weenie.
        Not being uncouth,
        He added vermouth
        And slipped his amour a martini.

        --
        --
        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/d/optout.
      • Brett Stahlman
        ... Tony, The semicolon is not meant to separate path entries: it s used to specify a stop directory for upward search. See the 2nd example in Upward
        Message 3 of 5 , Jun 8, 2014
        • 0 Attachment
          On Sunday, June 8, 2014 3:54:56 PM UTC-5, Tony Mechelynck wrote:
          > On 08/06/14 21:16, Brett Stahlman wrote:
          >
          > > Hello,
          >
          > > I've read the section on upward search (:help file-searching), and believe I
          >
          > > understand how it's supposed to work. The example in the help works the way I
          >
          > > expect on Linux, but not on Windows.
          >
          > >
          >
          > > Specifically, I created the following set of files and directories to match
          >
          > > the example from the help:
          >
          > >
          >
          > > C:/Users/stahlmanb/tmp/u/user_x/work/release/test.c
          >
          > > C:/Users/stahlmanb/tmp/u/user_x/include/test.h
          >
          > >
          >
          > > Note: To make things work on Windows, I've simply replaced Linux `/' with the
          >
          > > following Windows path: C:/Users/stahlmanb/tmp/
          >
          > >
          >
          > > Then, within Vim...
          >
          > > cd C:/Users/stahlmanb/tmp/u/user_x/work/release
          >
          > > e test.c
          >
          > > set path=include;C:/Users/stahlmanb/tmp/u/user_x
          >
          > >
          >
          > > Hitting gf with the cursor positioned on test.h (inside test.c) produces...
          >
          > > E447: Can't find file "test.h" in path
          >
          > >
          >
          > > I recreated the same test on Linux, replacing...
          >
          > > C:/Users/stahlmanb/tmp/
          >
          > > ...with...
          >
          > > /home/stahlman/tmp/
          >
          > > ...and everything worked as expected: test.h was found in the
          >
          > > /home/stahlman/tmp/u/user_x/include directory.
          >
          > >
          >
          > > Is there something I've missed that could explain the discrepancy, or is this
          >
          > > a bug?
          >
          > >
          >
          > > Thanks,
          >
          > > Brett Stahlman
          >
          > >
          >
          >
          >
          > In the 'path' option, a single dot means "the same directory as the
          >
          > file" and an empty item (two commas after each other) mean the current
          >
          > directory. Both are included in the default value. Also, that option is
          >
          > a _comma_-separated list, not a _semicolon_-separated list. See the
          >
          > example at the very end of the ":help 'path'" section, immediately
          >
          > before ":help 'preserveindent'".

          Tony,
          The semicolon is not meant to separate path entries: it's used to specify a "stop directory" for upward search. See the 2nd example in "Upward search" under file-searching in the help.

          As for the default 'path' setting... I'm not sure how that's relevant to this example, as I'm setting 'path' explicitly to a value that contains a single, non-empty element, followed by a single stop directory.

          Thanks,
          Brett Stahlman

          >
          >
          >
          >
          >
          > Berst regards,
          >
          > Tony.
          >
          > --
          >
          > There once was a fellow named Sweeney
          >
          > Who spilled gin all over his weenie.
          >
          > Not being uncouth,
          >
          > He added vermouth
          >
          > And slipped his amour a martini.

          --
          --
          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/d/optout.
        • Ben Fritz
          ... I also get this behavior on Windows in 7.4.292; likewise :find errors and tab-completion of :find just beeps. I tried omitting the C: , and also adding a
          Message 4 of 5 , Jun 9, 2014
          • 0 Attachment
            On Sunday, June 8, 2014 2:16:03 PM UTC-5, Brett Stahlman wrote:
            > Hello,
            > I've read the section on upward search (:help file-searching), and believe I
            > understand how it's supposed to work. The example in the help works the way I
            > expect on Linux, but not on Windows.
            >
            > Specifically, I created the following set of files and directories to match
            > the example from the help:
            >
            > C:/Users/stahlmanb/tmp/u/user_x/work/release/test.c
            > C:/Users/stahlmanb/tmp/u/user_x/include/test.h
            >
            > Note: To make things work on Windows, I've simply replaced Linux `/' with the
            > following Windows path: C:/Users/stahlmanb/tmp/
            >
            > Then, within Vim...
            > cd C:/Users/stahlmanb/tmp/u/user_x/work/release
            > e test.c
            > set path=include;C:/Users/stahlmanb/tmp/u/user_x
            >
            > Hitting gf with the cursor positioned on test.h (inside test.c) produces...
            > E447: Can't find file "test.h" in path
            >

            I also get this behavior on Windows in 7.4.292; likewise :find errors and tab-completion of :find just beeps.

            I tried omitting the "C:", and also adding a trailing "/" character, because of this statement in :help 'path': "A directory name may end in a ':' or '/'."

            Neither change made any difference.

            I think the problem is that u/user_x/work/release/include directory did not exist.

            When I create that directory, the upward search works to find ../../include/test.h.

            I think the relative path given as the search directory prior to the stop directories, actually needs to exist.

            I'm not sure whether this is documented, or even intentional.

            --
            --
            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/d/optout.
          • Brett Stahlman
            ... Yep. It works that way for me too. I m thinking this pretty much confirms it to be a bug - not only because it works differently on Linux, but also because
            Message 5 of 5 , Jun 9, 2014
            • 0 Attachment
              On Monday, June 9, 2014 10:15:19 AM UTC-5, Ben Fritz wrote:
              > On Sunday, June 8, 2014 2:16:03 PM UTC-5, Brett Stahlman wrote:
              > > Hello,
              > > I've read the section on upward search (:help file-searching), and believe I
              > > understand how it's supposed to work. The example in the help works the way I
              > > expect on Linux, but not on Windows.
              > >
              > > Specifically, I created the following set of files and directories to match
              > > the example from the help:
              > >
              > > C:/Users/stahlmanb/tmp/u/user_x/work/release/test.c
              > > C:/Users/stahlmanb/tmp/u/user_x/include/test.h
              > >
              > > Note: To make things work on Windows, I've simply replaced Linux `/' with the
              > > following Windows path: C:/Users/stahlmanb/tmp/
              > >
              > > Then, within Vim...
              > > cd C:/Users/stahlmanb/tmp/u/user_x/work/release
              > > e test.c
              > > set path=include;C:/Users/stahlmanb/tmp/u/user_x
              > >
              > > Hitting gf with the cursor positioned on test.h (inside test.c) produces...
              > > E447: Can't find file "test.h" in path
              > >
              >
              > I also get this behavior on Windows in 7.4.292; likewise :find errors and tab-completion of :find just beeps.
              >
              > I tried omitting the "C:", and also adding a trailing "/" character, because of this statement in :help 'path': "A directory name may end in a ':' or '/'."
              >
              > Neither change made any difference.
              >
              > I think the problem is that u/user_x/work/release/include directory did not exist.
              >
              > When I create that directory, the upward search works to find ../../include/test.h.
              >
              > I think the relative path given as the search directory prior to the stop directories, actually needs to exist.
              >
              > I'm not sure whether this is documented, or even intentional.

              Yep. It works that way for me too. I'm thinking this pretty much confirms it to be a bug - not only because it works differently on Linux, but also because it's difficult to conceive of a rationale for the Windows behavior, which seems to be, "Search upwards for an 'include' directory containing file "test.h", if and only if the current directory contains an 'include' directory that *doesn't* contain a file named "test.h" (since if cwd contains test.h, the upward search is skipped).

              I also wondered whether it could be a bug that has something to do with the Windows-specific characters in the absolute path...

              Thanks,
              Brett Stahlman

              --
              --
              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/d/optout.
            Your message has been successfully submitted and would be delivered to recipients shortly.