locations.conf has problems with Windows paths with backslashes

[zsquareplusc]

I wanted to have a different email in some branches therefore i added a section in locations.conf. However bzr whoami was showing the default until i changed all "\" to "/".

While i often prefer / and i am happy when applications accept it. But it must accept the normal Windows paths too.

This failed:

[C:\work\shared-repo]
email = ...

this works:

[C:/work/shared-repo]
email = ...

I ran bzr whoami within a branch of the shared repo as it does not check locations.conf when not in a branch.
BZR 2.0.0-1 WIndows standalone installer.

[Vincent Ladeuil (vila)]

I think the problem here is that \ is used as the escape character.
Does doubling it works ?
I.e.: try [C:\\work\\shared-repo] instead

[zsquareplusc (zsquareplusc)]

i did, an i just tested again,using "\\" does not improve the situation. I also tried "\\\\" and even "\\\" which also do not help.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

zsquareplusc wrote:
> i did, an i just tested again,using "\\" does not improve the situation.
> I also tried "\\\\" and even "\\\" which also do not help.
>

we do a match against are internal canonicalized form, which uses '/'
and not '\'. So I don't expect it to match.

One option would be to internally canonicalize the headings. Though you
run into some small issues with '\' being the escape character.

I think part of the problem is when it will/won't bite you. For example,
you may be fine doing:

C:\path

but then try to do

C:\todo

And it fails because '\t' is a valid escape for 'TAB'. Or

C:\newstuff

Suddenly thinks it needs a '\n'.

So whatever we *do* we need to be careful about consistency.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrBBZkACgkQJdeBCYSNAAP/oQCgnEIPyHQReas/yZEtek+1dd5w
WyMAn3OX6FzgO/CebBCCI4YRQflPNSgD
=Wp5b
-----END PGP SIGNATURE-----

[zsquareplusc (zsquareplusc)]

While it may be a little inconvenient to translate all copied and pasted path's slashes, it's feasible. However the restriction should be documented with a ".. note:" in the documentation.

Of course accepting paths with "\" would be even nicer. Windows has several dark edges where "/" in paths are not working :/