This is working as expected. Maybe we need to fix the docs. It's a path prefix, not a string prefix. You give it a path, and it strips the path, leaving you a relative path.

Do you have a reason to want it to work some other way?

If it's a relative path, then what is it relative to? I don't think I want a relative path as the result, and certainly the help output doesn't imply it will be.

Also, confusing is that other times, when trimpath is applied, it leaves the leading '/' on, I'll try to find a reproducible test case for that.

Ultimately, what I'm trying to do is this:

I want to pre-build the supplementary packages provided with Go in a proto area, but later, install them from a package into the system root. So the recorded paths should be an absolute path referring to the system root, not relative to some other area if I understand correctly.

The idea of -trimpath is that you are building in /tmp/iant-12345/ and you want to strip that prefix because it's not useful. The result is intended to be a relative path--it's relative to GOROOT or GOPATH, depending.

I want to pre-build the supplementary packages provided with Go in a proto area, but later, install them from a package into the system root. So the recorded paths should be an absolute path referring to the system root, not relative to some other area if I understand correctly.

That sounds more like GOROOT_FINAL than -trimpath. But GOROOT_FINAL is specific to GOROOT. I don't think we have a feature like that in the toolchain.

Well, in my case, I could strip the path so it would be relative to GOPATH, and that would work for my purposes (since GOROOT_FINAL already fixes all the paths for the standard Go library), but I guess I don't understand why -trimpath is supposed to produce a relative result, at least, that was unexpected to me. But I guess that's because as you said, it's a path not a string.

The help text should probably make it clearer that the result of applying trim is always a relative path.

I'll try to reproduce the other inconsistency I found with trimpath tomorrow and report back.

Ok, so after further experiment, I can't reproduce the behaviour I saw at one point, where trimpath behaved differently when I used a trailing slash.

Regardless, I find trimpath confusing for three reasons:

• it says "removes prefix from path" implying that prefix is treated as a string (to me anyway)
• it always produces a relative path result (which isn't clear from help text)
• if trimpath is really supposed to treat the input as a path to remove, then why does it care if I use a trailing slash or not? I find the behaviour of basically ignoring my input if I use a trailing slash to be surprising and unexpected.

Personally, it would be more useful to me if -trimpath produced a relative path if I used a trailing slash, and an absolute path if I did not. That would at least (to me) make some logical sense and would be easy to explain.

I suppose I personally don't mind if you want to change it, but the truth is that we don't really expect people to invoke -trimpath themselves. It's there for the Go tool to use, and it's documented for completeness.

Ok, if there are no objections then I'd be happy to contribute such a change. -trimpath makes it possible to easily distribute prebuilt Go packages so is pretty valuable for an OS distribution. I'll do some testing and further evaluation first and then propose something specific. Thanks for your patience and kind response.