Re: surprising glob() result on Windows

On 05/02/2023 3:53 PM, Bram Moolenaar wrote:
>
>> Just out of curiosity, I tried the same with python and tcl. Neither
>> returns multiple files for the *.abc case so their behavior is
>> different. I don't know why it differs but I would argue that their
>> outputs do a better job of "meeting expectations".
>
> That depends on what your expectations are. If you list a directory and
> see a file "some~1.abc" then a glob() with *.abc should find it, right?
> Or not? The question is whether you expect to match the long name only.

On my Windows 10 system with NTFS, Windows Explorer and dir will, by
default, show "some.abcd" and not "some~1.abc". Therefore I don't
expect glob("*.abc") to return "some.abcd".

However, the command "dir /X" will display the short-filename
equivalents but I never use that option and suspect that few do.

>
> Usually when we encounter something where it's not 100% clear what the
> right behavior is, the best choice is to leave it alone. The people who
> are happy with the current behavior won't make any remark right now,
> thus we have no idea how many we would "hurt" by making a change.
>
>> Perhaps this is an issue I should raise with the vim developers for the
>> following reasons. First, the Windows outputs are inconsistent with the
>> linux outputs for the same directory contents.
>
> Still, there have been no complaints until now. It appears to be more a
> theoretical problem than a practical one.
>
> Adding an optional argument to glob() to avoid the short filenames is
> not a good idea, there already are three optional arguments. We could
> change this to use a second argument that is a dictionary with the
> current options plus the new one. It would be clearer when reading back
> the function call. Is it really worth making this change?
>
>> Second, it appears that vim is using this glob capability when
>> sourcing plugins (I first noticed this using packadd) and so unwanted
>> files could be sourced on Windows systems.
>
> Can you be more specific about "when sourcing plugins" ?
> Are there really files using an extension starting with ".vim"?
>

By "sourcing plugins" I mean what Vim automatically does when it starts
up and what it does when it executes the "packadd" command. If a
"plugin" directory includes a file with the extension .vim9 for example,
it will be sourced, apparently because the filesystem, if it supports
short filenames, has a duplicate name for "some.vim9" which could be
"some~1.vim".

I do admit that I don't know what actually happens under-the-covers
because Vim-glob does return "some.vim9" and not "some~1.vim". As I
mentioned above, the python & Tcl glob commands do not return some.vim9
when the pattern is *.vim so their behavior is different.


--
--
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@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/u2rski%24s25%241%40ciao.gmane.io.