Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: list --search matching and Windows *-expansion
To: dev@subversion.apache.org
References: <CAB84uBVz1N_E-1pVJqQ_eAMm8antfnPg0zy19_5UNhCQu_0urg@mail.gmail.com>
 <627ab8f1-235f-b4b9-6ae6-44d89212e77a@apache.org>
From: =?UTF-8?Q?Branko_=c4=8cibej?= <brane@apache.org>
Organization: The Apache Software Foundation
Message-ID: <2d0ef1e5-b57f-3750-e465-f7fff1fc034c@apache.org>
Date: Mon, 18 Dec 2017 16:24:41 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <627ab8f1-235f-b4b9-6ae6-44d89212e77a@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
archived-at: Mon, 18 Dec 2017 15:24:48 -0000

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@visualsvn.com> wrote:
>>> Stefan Fuhrmann <stefan2@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