Well, you never know when you've got incomplete information

There's no information missing. The source is on CPAN. Feel free to check it. You'll find the same thing.

I can't imagine why the code would change only the first part of the path to "\\". So I asked

Probably because you think something was changed. It's what you get when you place a path seperator between '' and '/foo/go/do'. That's fine on unix, but not on Windows.

No, I meant that given the text he fed it, "/foo/go/do", and assuming the module was doing what it was supposed to, I couldn't imagine why would it return "\\foo\go\do". The module actually does attempt to identify UNC pathnames (\\server\path\path), as well as drive letters (D:\Windows), and simple root folders (\users\me); so since the module is returning the text it is, it did not seem unreasonable to ask the OP if there is a server involved. It seems a bug like this surely would have been noticed before.

Anyway, I've been playing with version 3.33, the current version, on Vista and I'm not seeing the OP's results.

What did you get, then?

canonpath: \foo\go\do
catfile: \foo\go\do
[download]

I meant information missing from the OP's post. Why would you think I meant information missing from the module? That makes no sense!

I thought you were replying to the content of the parent post. I have no idea what information you think is missing, and for what purpose it's missing.

assuming the module was doing what it was supposed to, I couldn't imagine why would it return "\\foo\go\do".

So you can't even imagine them helping either, but you recommended trying them anyway? I suppose there's nothing lost by trying, thought I'm not sure how one goes about trying to get buggy results.

I got I got the correct and expected [...] \foo\go\do

That's what the OP is getting. It's not what he's expecting/desires.

I meant information missing from the OP's post. Why would you think I meant information missing from the module? That makes no sense!

I thought you were replying to the content of the parent post. I have no idea what information you think is missing, and for what purpose it's missing.

Weeellll, I was replying to the parent post. You see, sometimes someone posts a question, and they leave out information which could make it easier to figure out what they need. So some of us ask questions to draw out what the problem was. I don't know why this confuses you. Are you just twisting my words for fun?

assuming the module was doing what it was supposed to, I couldn't imagine why would it return "\\foo\go\do".

So you can't even imagine them helping either, but you recommended trying them anyway? I suppose there's nothing lost by trying, thought I'm not sure how one goes about trying to get buggy results.

Weeellll, since this paragraph doesn't seem to make sense either, except for being sarcastic and hostile, I'm not going to say much here. I wrote something off the cuff that I thought might be helpful. In hindsight, it was off the mark. Mea culpa.

I got the correct and expected ... \foo\go\do

That's what the OP is getting. It's not what he's expecting/desires.

Weeellll, actually, we have already established that the correct answer is \foo\go\do. And we have established that unless there's a UNC pathname involved, we would expect the path to resolve to \foo\go\do. Soooo, I think we are already in agreement that this is the correct and expected result.

The OP had expected something different, but I think we have also established that he is aware that they were relying on what turned out to be a side effect of a bug that shows itself when you try to concatenate an empty string with an existing path -- and he's said they will change their code and/or processes. But I think you knew this.

Forgive me, El Ikkey. I know that I, marmot, do not have your superior intellect and education. But could it be that once again, you are angry at something else, and are looking to take it out on me?

--marmot