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
