list --search matching and Windows *-expansion

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 ...

[1] https://stackoverflow.com/questions/47512829/is-it-possible-to-quote-escape-command-line-arguments-on-windows-while-linking-s

[2] https://svn.haxx.se/dev/archive-2017-09/0002.shtml

-- 
Johan