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

Re: [patch] problem with backslash escaped strings in expand(), glob(), etc...

Expand Messages
  • Christian Brabandt
    Hi Bram! ... On Unix a filename can contain backslashes. glob/expand shoudln t skip them. Or saying it differently, I don t see a reason for expand() to change
    Message 1 of 3 , Nov 9, 2012
    • 0 Attachment
      Hi Bram!

      On Mi, 07 Nov 2012, Bram Moolenaar wrote:

      >
      > Christian Brabandt wrote:
      >
      >
      > > there seems to be a problem with backslash escaped strings when using
      > > expand(), glob() or globpath():
      > >
      > > #v+
      > > cb@host: mkdir -p /tmp/test
      > > ch@host: touch /tmp/test/bar /tmp/teest/foo\\1
      > > cb@host: vim -u NONE -U NONE -N -c ':e /tmp/test/bar|echo
      > > expand(@#)|echo expand("#")' /tmp/test/foo\\1
      > > #v-
      > >
      > > This outputs:
      > > "/tmp/test/bar" 0L, 0C
      > > test/foo1
      > > test/foo\1
      > >
      > > The problem is, you can't rely on expand() to skip one backslash,
      > > because on Windows it behaves correctly (e.g. expand('foobar\1') on
      > > Windows returns 'foobar\1' while on Unixs returns 'foobar1').
      >
      > Yeah, handling a backslash in a filename gets tricky on MS-Windows, you
      > don't always know if it is used as a path separator or to escape the
      > special meaning of a character.
      >
      > On the command line backslashes are accepted as path separators on
      > Windows, thus it will be different from Unix. That is intentional and
      > should not be changed.
      >
      > For functions it gets tricky. And then we also have 'shellslash'. Thus
      > it probably won't ever be consistent.
      >
      >
      > > Also, you can't use glob('/tmp/test/foo\\1') to return the correct
      > > result, and if you use glob(expand(path)) where path contains a
      > > backslash, glob() won't return the empty string.
      > >
      > > This is problematic because glob() is mentioned below :h filereadable()
      > > to check for the existence of a file.
      >
      > Why would you use "\\1" here? It doesn't have a special meaning, thus
      > perhaps the user actually wanted two backslashes?

      On Unix a filename can contain backslashes. glob/expand shoudln't skip
      them. Or saying it differently, I don't see a reason for expand() to
      change it's input, if it can't expand the input parameter, it should
      return in unchanged.

      > > Here is a patch, that fixes this problematic behaviour and makes it at
      > > least consistent to the Windows behaviour. But ... it is a backward
      > > incompatible change and probably breaks a lot of plugins, that work
      > > around that bug by using something like
      > >
      > > if glob(expand(escape(filename, '\\')))
      > > " file exists
      > > &
      > > else
      > > " create file
      > > &
      > > endif
      > >
      > > Nevertheless, I tend to consider this as a bug and would like it to work
      > > consistently on all plattforms.
      >
      > As mentioned, consistency is not really a goal here, MS-Windows handles
      > backslashes differently. We need a better reason to make backwards
      > incompatible changes.

      I don't really mind, but it should be mentioned, that expand/glob
      changes it input.

      regards,
      Christian
      --
      Musik im besten Sinne bedarf weniger der Neuheit, ja vielmehr,
      je älter sie ist, je gewohnter man sie ist, desto mehr wirkt sie.
      -- Goethe, Maximen und Reflektionen, Nr. 1235

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