[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: list --search matching and Windows *-expansion

From: Branko Čibej <brane_at_apache.org>
Date: Mon, 18 Dec 2017 16:24:41 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.