Branko Čibej wrote on Mon, 18 Dec 2017 16:24 +0100:
> On 18.12.2017 15:33, Stefan Fuhrmann wrote:
> > On 18.12.2017 15:20, Johan Corveleyn wrote:
> >> 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.
>
+1 to the general concept of keeping the Unix API unchanged.
However, this specific solution doesn't allow Windows users to use
"foo*bar" patterns (= embedded asterisks).
> 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.
I'm concerned about API divergence between Windows and Unix. Could we
try to minimise the possibilities for Windows admins to write code (say,
Python code using subprocess.check_call()) that won't work on Unix, and
vice-versa?
For example, how about if we only perform the substitution you describe
if the pattern had a magic prefix, so «--search "nostar:foo#bar%"» would
pass "foo*bar?" to the API's on *all* platforms? This way, Windows code
would work on Unix, and Unix code that actually searches for percent signs
would work on Windows.
Received on 2017-12-18 19:01:56 CET