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