On 18.12.2017 15:20, Johan Corveleyn wrote:
On Tue, Dec 5, 2017 at 10:12 PM, Evgeny Kotkov
<evgeny.kot...@visualsvn.com> wrote:
Stefan Fuhrmann <stef...@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.)
Spinning off this discussion from the "Subversion 1.10 RC1?" thread ...
Do we still want to fix this somehow for 1.10?
Doug Robinson pointed out that there is no way to escape * from the
shell on Windows [1]. And Branko hinted at doing the glob expansion
ourselves, instead of depending on setargv.obj, but that didn't seem
very realistic (as in: is there someone to do the work?).
Another option is the cheap solution that Evgeny proposes: always
doing substring matching. We discussed that before [2], and most were
not in favor of it, but maybe we have no choice ...
Elsethread, it was already mentioned that only the command
line client under Windows is effected; other Windows clients
like TSVN and language bindings are fine.
So, lets add a workaround in the Windows CL client only such
that it will use sub-string search. This will make the new
option still quite useful for Windows admins (i.e. the people
that might use the CL client). Technically, the client will
pass the "*ParameterValue*" pattern to the underlying libs.
#ifdefs will guard that behavior.
If nobody objects, I'd like to commit the patch tomorrow.
-- Stefan^2.
