[PATCH] Tests with spaces in paths

[Matt Mackall]

On Tue, 2010-03-30 at 02:33 +0200, Mads Kiilerich wrote:
> Matt Mackall wrote, On 03/29/2010 08:40 PM:
> > On Wed, 2010-03-24 at 01:51 +0100, Mads Kiilerich wrote:
> >    
> >> Note that for example ui.patch, ui.editor, the bisect command, ssh
> >> command and HGMERGE are command line fragments and must be properly quoted.
> >>      
> > As are hooks.
> >    
> >> The commands used for extdiff and "new" merge-tool configuration are
> >> however "executables" and will be quoted automatically, so command line
> >> fragments can not be used there.
> >>      
> > The merge tool stuff lets you configure the command line separately.
> >    
> >> Is that intended? Should these (and similar) differences be fixed or
> >> documented?
> >>      
> > How would you propose fixing it?
> >    
> 
> In case you don't think there is anything here that needs fixing I won't 
> waste time trying to fix it. But it seems like you are not directly 
> opposed to sane changes in this area.
> 
> 
> In 17da88da1abd you changed bisect from "auto-quoted command" to 
> "command line fragment" with this reasoning:
> > The existing scheme using util.find_exe and subprocess.call meant we
> > couldn't use simple shell commands in tests. Fix that.
> 
> Perhaps we could do that in more / all places and thus give a more 
> consistent user experience and generally make quoting somebody elses 
> problem.
> 
> Extdiff could be one candidate for that.
> 
> The current merge tool configuration is fine - as long as you don't want 
> to use "python ../merge" as merge tool. If we really want consistency we 
> could add extra merge-tools.x.check=../merge that find_exe could look 
> for, so that .executable could be empty and we could use .args=python 
> ../merge $base $local $other $output
> 
> 
> As long as this area isn't clearly documented (AFAIK) we can claim that 
> it was unspecified behaviour and change it. Alternatively we could just 
> improve the documentation. What would be preferred?

Generally we want to support full command lines where possible. So the
above seems pretty sensible.

-- 
http://selenic.com : development and support for Mercurial and Linux