[Bug 425510] Re: 'bzr mv' should do wildcard expansion on windows

[Alexander Belchenko]

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> John Arbash Meinel ?8H5B:
>>> Vincent Ladeuil wrote:
>>>>>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:
>>>> <snip/>
>>>>     martin> Perhaps a better way to tackle this is for the
>>>>     martin> declaration of the argument pattern taken by the
>>>>     martin> command to declare which arguments will be subject to
>>>>     martin> expansion?
>>>> +1
>>>>         Vincent
>>>
>>> So there is actually a way to get access to the original command line
>>> string that was passed. If you look at:
>>>  bzrlib.win32utils.get_unicode_argv
>>>
>>> it does:
>>>   pargv = CommandLineToArgv(GetCommandLine(), ctypes.byref(c))
>>>
>>> GetCommandLine() gives you the raw Unicode string as supplied by the
>>> caller. Which means that it has all the quoting characters, etc.
>>>
>>> So we could simply replace "CommandLineToArgv()" with a function that
>>> was more 'Unixy'.
>> If by 'Unixy' you mean 'using shlex' then you will make things only worse.
> 
> shlex doesn't support Unicode, as I understand it. But we could:
> 
> 1) Support both '' and "" as quoting characters. (CommandLineToArgv only
> supports "")

It's not big deal IMO.

> 2) Support globbing, as it becomes clear whether the user typed:
>   "*.foo" versus *.foo versus '*.foo'
> 
>   not to mention '*.foo bar' versus *.foo bar

This is only one thing which make sense. So you can GetCommandLine(),
expand wildcards and then call CommandLineToArgv.

> 3) I'm not sure about env var substitution, but I'm pretty sure that
> %FOO% expansions happens before we get the command line. I haven't
> tested that much.

This is my impression as well.

> 4) I don't know what shlex does/doesn't support specifically. Though if
> you have specific points that you know it "is worse", then it would be
> good to keep in mind for whoever wants to implement this.

Yes. The problem is backslashes:

In [12]: import shlex

In [13]: shlex.split('bzr init C:\\work\\foo\\bar')
Out[13]: ['bzr', 'init', 'C:workfoobar']

I think this behavior is *inappropriate* at all.

> IMO, this is the best place to do it. As it basically is what we are
> used to happening on other platforms. It seems to be at the right level
> (expanding the supplied command string, before the list of arguments is
> determined.) It should work appropriately for all commands, and gives
> the user the ability to use "" to avoid globbing.
> 
> Note that right now, 'bzr add' *cannot* handle:
>   bzr add "*.foo"

On Windows it actually can:

C:\Temp>bzr init 3
Created a standalone tree (format: pack-0.92)

C:\Temp\3>echo > "bar.foo"

C:\Temp\3>bzr add "*.foo"
adding bar.foo

> I don't think it matters a lot, mostly because '*' is not an allowed
> character in Windows filenames.

If you mean that quotes should prevent glob expansion on Windows (in theory when your idea wil be
implemented) then yes.

> Probably the biggest reason is that it provides consistency across
> platforms.
> 
> Also, I should mention that *I'm* not planning on doing this, as
> cygwin's expansion works just fine for everything I need.
> 
> John
> =:->
>