On 18.12.2017 15:33, Stefan Fuhrmann wrote:
> 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.
Or use a different set of match chars on Windows instead of * and ?, as
a hacky but usable workaround. That would mean that, only on windows,
and in the argument of --search, we would replace, say, % and # with *
and ? or some such. I'd even go as far as to add a warning that this
substitution will be removed once (if?) we get rid of setargv.obj.
-- Brane
Received on 2017-12-18 16:24:48 CET