Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OS X: read /etc/manpaths and /etc/manpaths.d #1092

Closed
daenney opened this issue Nov 3, 2013 · 6 comments
Closed

OS X: read /etc/manpaths and /etc/manpaths.d #1092

daenney opened this issue Nov 3, 2013 · 6 comments

Comments

@daenney
Copy link

daenney commented Nov 3, 2013

Similar to /etc/paths and /etc/paths.d OS X has /etc/manpaths and /etc/manpaths.d which should be used to populate the $MANPATH environment variable.

@ridiculousfish
Copy link
Member

Sounds reasonable

@lilyball
Copy link
Contributor

OS X uses a tool /usr/libexec/path_helper to construct the default PATH and MANPATH vars. This tool only defines MANPATH if the MANPATH variable is already set. Since it's executed as the first thing in /etc/profile, which is the first file Bash sources, AFAIK the only way to actually have the MANPATH be set up is if Bash inherits a MANPATH variable from its environment.

To that end, if we do adopt this same behavior (and we don't decide to do it by invoking path_helper ourselves and parsing the output into something Fish-compatible), we should match that expectation and only set MANPATH if it's already set. The reason for this behavior is because, by leaving MANPATH un-set, man constructs its own search path based on the PATH variable.

@krader1961
Copy link
Contributor

@kballard I wrote this blog article about why MANPATH doesn't work on OS X less than six months ago. I admit I did not expend much effort in figuring out why it didn't work. But I eventually gave up and added the following comment to my environ.fish file (and before that the equivalent zsh file) which is sourced from my ~/.config/fish/config.fish file:

# Setting $MANPATH is pointless on Mac OS X as it is ignored. Only
# paths in /etc/man.conf are recognized.

I would not be offended to learn that despite using OS X for over a decade I misunderstood this aspect of its behavior.

@lilyball
Copy link
Contributor

@krader1961 That blog post is rather perplexing, because I just tried and it worked just fine.

> brew install coreutils
[...]
> env MANPATH=/usr/local/opt/coreutils/libexec/gnuman man -w ls
/usr/local/opt/coreutils/libexec/gnuman/man1/ls.1

If I run a Bash login shell with that MANPATH set, so as to make /usr/libexec/path_helper give me a complete MANPATH that includes the built-in stuff, then it sorts it such that man ls still gives me the built-in one, but man -a ls gives me both the built-in and the coreutils manpage.

@daenney
Copy link
Author

daenney commented Feb 27, 2016

I've so far never had any issues with OS X ignoring or not respecting MANPATH. Setting it is how I make sure all the man pages that get coupled with projects installed from brew show up when I do a man <thing from brew> and how I then have it generate completions for it by calling fish_update_completions.

ridiculousfish pushed a commit that referenced this issue Dec 27, 2016
…1092.

   * Only append paths if `MANPATH` is already set, to match behavior of macOS
     `path_helper` utility.
   * Use the same technique as is used above to set PATH from /etc/paths and
     /etc/paths.d/*.
@krader1961
Copy link
Contributor

This has been resolved but wasn't automatically closed because the commit did not include the magic line "Fixes #1092".

@krader1961 krader1961 modified the milestones: fish-future, next-major Mar 29, 2017
@zanchey zanchey modified the milestones: fish 2.5.0, fish-future Mar 29, 2017
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants