On 18.12.2017 15:20, Johan Corveleyn wrote:
> On Tue, Dec 5, 2017 at 10:12 PM, Evgeny Kotkov
> <evgeny.kotkov_at_visualsvn.com> wrote:
>> 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.)
>
> 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.
Received on 2017-12-18 15:33:36 CET