Op 5 dec. 2017 22:13 schreef "Evgeny Kotkov" <evgeny.kotkov_at_visualsvn.com>:
Stefan Fuhrmann <stefan2_at_apache.org> writes:
> There seems to be little that could be done here (suggestions welcome).
> The problem is that the asterisk is being expanded by the shell itself.
> I made SVN print its command line parameters and this is the result:
>
> $ ./subversion/svn/svn ls svn://localhost/kde --search M*
> 0: ./subversion/svn/svn
> 1: ls
> 2: svn://localhost/kde
> 3: --search
> 4: Makefile
> 5: Makefile.in
>
> That can be prevented by adding quotation marks:
>
> $ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
> 0: ./subversion/svn/svn
> 1: ls
> 2: svn://localhost/kde
> 3: --search
> 4: M*
Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
would expand the asterisk. While this is not the default shell behavior,
currently it's enabled for svn and a couple of other binaries by linking
to setargv.obj. In turn, this probably means the command-line client
users on Windows could get quite unexpected results when using the
`--search ARG` syntax.
A potential cheap solution for this issue, I think, would be to make the
--search argument work as a substring to search for in filenames, instead
of using it as a pattern that the (whole) filename should match. While
there are some cases where the latter approach gives more flexibility,
my guess would be that a substring search would work well in the majority
of scenarios.
(Also, as far as I recall, `log --search` currently searches for a
substring,
so that would be consistent with it, and would probably avoid surprising
the users by having a switch with the same name, but behaving differently.)
Thanks,
Evgeny Kotkov
(Sorry if quoting is broken above ... I blame Google)
We've discussed whether ls --search should always match substrings or exact
before, and the people participating in that thread were in favor of exact
matching:
https://svn.haxx.se/dev/archive-2017-09/0002.shtml
Consistency with log --search also came up, but wasn't a good argument for
most.
Of course, if this would be the only way to make this work on Windows, some
people might reconsider ...
--
Johan
Received on 2017-12-05 23:32:08 CET