On 21.12.2017 14:50, Stefan Fuhrmann wrote:
> On 19.12.2017 11:06, Stefan Sperling wrote:
>> On Mon, Dec 18, 2017 at 08:59:08PM +0000, Julian Foad wrote:
>>> Stefan Sperling wrote:
>>>> On Mon, Dec 18, 2017 at 06:01:52PM +0000, Daniel Shahaf wrote:
>>>>> Branko Čibej wrote on Mon, 18 Dec 2017 16:24 +0100:
>>>>>> Or use a different set of match chars on Windows instead of * and
>>>>>> ?, as
>>>>>> a hacky but usable workaround. [...]
>>> [...]
>>>>> a magic prefix, so «--search "nostar:foo#bar%"» [...]
>>> [...]
>>>> define some mapping between our fnmatch special chars
>>>> [...] Windows users would [...] use the set of chars which works
>>>> for them.
>>> Reality check, please!
>>>
>>> This is meant to be a simple feature to help people find files, is
>>> it not?
>>>
>>> Magic prefixes and non-standard wildcard chars are a non-starter for
>>> usability.
>>>
>>> It would be better to disable the whole '--search' option, or the
>>> wildcard
>>> support in it, on the Windows CLI.
>> I think we should keep coming up with more ideas until somebody gets
>> enough
>> of it all and sends a patch to remove our dependency on setargv.obj :)
>>
> Well, that escalated quickly ;)
>
> While I liked Brane's idea for being easy to implement,
> I think Julian's point concerning usability is stronger.
> Therefore, I will go with my initial proposal to make
> 'svn ls --search' in the Windows CLI work the same as
> 'svn log --search'.
>
> Given that we have fnmatch available, replacing setargv.obj
> in 1.11 should not be too much of an effort. I don't have
> access to a Windows environment ATM, though.
It's not as simple as all that. We should not just replace setargv.obj
but also implement some kind of quoting (preferably compatible with the
Windows command line in general). Otherwise the wildcard expansion logic
will bleed into the argument interpretation, and we definitely do not
want to fill the command-line code with a mountain of #ifdefs.
-- Brane
Received on 2017-12-21 15:04:38 CET