Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 18 Dec 2017 19:14:36 +0100
From: Stefan Sperling <stsp@elego.de>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: dev@subversion.apache.org
Subject: Re: list --search matching and Windows *-expansion
Message-ID: <20171218181436.GC97781@ted.stsp.name>
Mail-Followup-To: Daniel Shahaf <d.s@daniel.shahaf.name>,
	dev@subversion.apache.org
References: <CAB84uBVz1N_E-1pVJqQ_eAMm8antfnPg0zy19_5UNhCQu_0urg@mail.gmail.com>
 <627ab8f1-235f-b4b9-6ae6-44d89212e77a@apache.org>
 <2d0ef1e5-b57f-3750-e465-f7fff1fc034c@apache.org>
 <1513620112.213942.1209016936.21B9885B@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1513620112.213942.1209016936.21B9885B@webmail.messagingengine.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
archived-at: Mon, 18 Dec 2017 18:14:51 -0000

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

How about we use Brane's idea, but with a twist:

Essentially, we'd define some mapping between our fnmatch special chars
and another set of chars that won't cause problems on a windows command
line, chosen as needed to work around this windows-specific issue in
our command line client.

Then we could keep supporting these aliases on all platforms and it
wouldn't matter which set of chars people use. Windows users would
of course be advised to use the set of chars which works for them.