Robert Collins wrote:
> On Sat, 2009-11-07 at 16:30 +0000, Gordon Tyler wrote:
>> Review: Approve
>> Handling of quoted commandline arguments is the responsibility of the shell.
>
> So is glob expansion, but we do that in bzr on windows. Why is glob
> expansion something bzr should do, but not quoting?
>
> John - does
> c:\foo\> bzr commit -m "foo'bar"
> work at the moment ? If not, we should fix that - on unix we'd want
> "foo'bar" not "foobar" as the resulting string.
>
> For now, I'm abstaining, as I don't use windows either. I *do* think it
> would be very nice to be able to have our docs be the same for win32 and
> unix as far as handling paths with spaces.
>
> -Rob
>
bzr commit -m "foo'bar" works as you would expect. The change is that:
bzr commit -m foo'bar
is treated as "foobar". Normally your shell would hang waiting for you
to close your quotes. We get the string late, so can't really do that.
(We *could* error, though.)
Note that this patch "breaks"
bzr commit foo'bar
as it doesn't support
bzr commit foo\'bar
though I'll note that you could have a file named "'bar". In Unix world
you would commit that with
bzr commit foo/\'bar
I don't really know how to express it in something similar-enough to
Windows shell...
bzr commit foo\\\'bar ?
Note that Windows works around not having an escape character by just
not allowing characters that you would otherwise want to escape as a
valid filename. So you can't have:
bzr commit foo"bar
" is not allowed (and neither is *?<>/\:...)
It wouldn't be hard to update the parser to allow:
bzr commit foo\'bar
And allowing that we also need
bzr commit foo\\\'bar
of course.
(we don't *need* foo\"bar since " isn't allowed in filenames, and we
have it already for 'bzr commit -m "foo \" bar"')
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Collins wrote:
> On Sat, 2009-11-07 at 16:30 +0000, Gordon Tyler wrote:
>> Review: Approve
>> Handling of quoted commandline arguments is the responsibility of the shell.
>
> So is glob expansion, but we do that in bzr on windows. Why is glob
> expansion something bzr should do, but not quoting?
>
> John - does
> c:\foo\> bzr commit -m "foo'bar"
> work at the moment ? If not, we should fix that - on unix we'd want
> "foo'bar" not "foobar" as the resulting string.
>
> For now, I'm abstaining, as I don't use windows either. I *do* think it
> would be very nice to be able to have our docs be the same for win32 and
> unix as far as handling paths with spaces.
>
> -Rob
>
bzr commit -m "foo'bar" works as you would expect. The change is that:
bzr commit -m foo'bar
is treated as "foobar". Normally your shell would hang waiting for you
to close your quotes. We get the string late, so can't really do that.
(We *could* error, though.)
Note that this patch "breaks"
bzr commit foo'bar
as it doesn't support
bzr commit foo\'bar
though I'll note that you could have a file named "'bar". In Unix world
you would commit that with
bzr commit foo/\'bar
I don't really know how to express it in something similar-enough to
Windows shell...
bzr commit foo\\\'bar ?
Note that Windows works around not having an escape character by just
not allowing characters that you would otherwise want to escape as a
valid filename. So you can't have:
bzr commit foo"bar
" is not allowed (and neither is *?<>/\:...)
It wouldn't be hard to update the parser to allow:
bzr commit foo\'bar
And allowing that we also need
bzr commit foo\\\'bar
of course.
(we don't *need* foo\"bar since " isn't allowed in filenames, and we
have it already for 'bzr commit -m "foo \" bar"')
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
12V4ACgkQJdeBCY SNAANneACdGJCsd 4JdfElOr+ /Zi+9u+ ARu aPneEqHXqTvgDmY zL4QUp
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkr
tfgAn3C4hu+
=Tiv0
-----END PGP SIGNATURE-----