opam config env appears to blow away MANPATH

[pmetzger]

opam config env appears to completely replace the contents of the existing MANPATH variable instead of prepending the appropriate .opam/something/man directory. If the variable is already set, it should only prepend rather than throwing away the existing contents. Also, if the variable is empty, it should not place a : into the MANPATH.

[dra27]

Which version of opam, please? Is this is a duplicate of #2870?

[pmetzger]

$ opam --version
1.2.2

I'm running on MacOS 10.13.4, if that's of use.

[AltGr]

Looks indeed like #2870 ;

Also, if the variable is empty, it should not place a : into the MANPATH.

precisely, on some (most?) systems, it should. On Debian systems, man manpath shows:

If $MANPATH is set, manpath displays its value rather than determining it on the fly. If $MANPATH is prefixed by a colon, then the value of the variable is appended to the list determined from the content of the configuration files. If the colon comes at the end of the value in the variable, then the determined list is appended to the content of the variable. If the value of the variable contains a double colon (::), then the determined list is inserted in the middle of the value, between the two colons.

But indeed, the same page on OSX reads:

If MANPATH is set, man uses it as the path to search for manual page files. It overrides the configuration file and the automatic search path, but is overridden by the -M invocation option.

which seems consistent with the results we are seeing. In the latter case, however, the manpath command uses clever heuristics to find the correct manpages for utilities in the PATH, so no update from opam is needed!

Unfortunately, we don't have an operator "prepend/append only if variable is already set", and that would be a bit tedious to add right now (needs extending the parser, etc.), so the simpler solution seems to be not to set MANPATH on any BSD-likes. Still wonder about the original case for #2870, which was on Debian, though.

[pmetzger]

Ah, I now understand the purpose of the : (which isn't the case on all systems, how irritating.) Regardless, it is probably the case that the command should not blow away an existing setting.

[pmetzger]

Is this being closed because it duplicates #2870?

[dra27]

No - it's been fixed! Follow the link from the commit

[pmetzger]

Ah, excellent!

[pmetzger]

Hrm. Has it really been fixed? Yes, it will work for me on MacOS now, but on Linux what will it do? #2870 still seems to be a variation on the issue.