On 19.03.2014 12:29, Bert Huijben wrote:
> Normal Windows applications don't expand '*' directly when passed on the
> commandline (and neither does the Windows default shell). So before this
> patch *all* our applications were special in their handling of '*' and '?',
> while after this patch only the two applications that really use the
> wildcard expansion are special while the other applications work like all
> the other applications from all other sources.
>
> It is not that we as Subversion project can set a standard with millions of
> other applications out there. I don't think Windows users think about the
> argument parsing as being different for svn applications and other
> applications.
I don't really care about what you call "normal" Windows applications;
there aren't any such beasts.
> The best fix for Windows users would be to remove the special handling from
> 'svn' and 'svnadmin' too, and handle the wildcard expansion in the argument
> parsing logic *after* we separate them from arguments that don't point to
> local paths... This is how well behaved Windows applications do things.
No. We explicitly and intentionally included setargv.obj in the Windows
link for command-line tools in order to make them behave approximately
the same way as on Unix.
> But this would involve adding a lot of Windows support to apis and/or the
> svn client that aren't used for this kind of things on other platforms.
Exactly. Not our problem.
> With reducing the scope of the 'special argument parsing' to the tools that
> really need this, all other applications are much easier to use by scripts,
> where they had to apply hacks to provide arguments that may contain a '?' or
> '*', because there is no way to escape the arguments at this level.
I disagree. It's more important that the tools behave similarly across
different platforms. Making some tools behave differently for others to
save people some argument quoting woes is just silly.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-03-19 14:01:35 CET