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

Fix manpath handling in create_manpage_completions.py #6879

Merged
merged 3 commits into from May 7, 2020
Merged

Fix manpath handling in create_manpage_completions.py #6879

merged 3 commits into from May 7, 2020

Conversation

neersighted
Copy link
Contributor

...as well as do some (very!) light cleanup.

Currently, create_manpage_completions.py does not properly
understand/respect the $MANPATH variable. One important feature of
$MANPATH is that an empty component (i.e. the trailing : in
foo:bar:) expands to the 'default' or 'system' path -- that is to say,
the path that would be used if $MANPATH was unset. This allows the
user to extend the manpath without clobbering it, and has been a feature
many Unices have included for years.

The current implementation blindly uses the $MANPATH variable if it
exists, which does not allow for this behaviour -- to expand the
variable correctly, an external program must be invoked. Therefore, we
first shell out to the 'proper' (read: best guess) external program. If
that fails, we can then try to use $MANPATH directly/literally.
Finally, if both of those are impossible, we can fall back to some
common paths from widely used operating systems.

Note that the man.conf parsing has been removed: this is because while
many 'traditional' Unices (BSDs, Solaris, macOS) support this file, only
macOS actually ships a file -- most other Unices use a conf.d-style
layout and supporting that from our Python is impractical and silly at
best. On GNU (read: Linux) systems, mandb uses /etc/man_db.conf with
slightly different syntax and sematics. As this code-path has bitrotted
(and likely never worked, anyway), just remove it.

create_manpage_completions.py looks like it has suffered a lot of
confusion and bitrot in general over the last few years -- and is
overdue for a major refactoring. I am quite interested in tackling this,
but I plan to wait until the go-ahead to drop support for Python 2 is
given, as a major refactor/rewrite that still supports Python 2 (and
thus ignores the ergonomic/API/syntax improvements of Python 3) does not
make sense to me.

Related: #5657

It would probably be good to revisit man.fish once again when a
comprehensive refactor happens: hopefully every permutation of
man/$MANPATH could be documented as part of that effort.

...as well as do some (very!) light cleanup.

Currently, `create_manpage_completions.py` does not properly
understand/respect the `$MANPATH` variable. One important feature of
`$MANPATH` is that an empty component (i.e. the trailing : in
`foo:bar:`) expands to the 'default' or 'system' path -- that is to say,
the path that would be used if `$MANPATH` was unset. This allows the
user to extend the manpath without clobbering it, and has been a feature
many Unices have included for years.

The current implementation blindly uses the `$MANPATH` variable if it
exists, which does not allow for this behaviour -- to expand the
variable correctly, an external program must be invoked. Therefore, we
first shell out to the 'proper' (read: best guess) external program. If
that fails, we can then try to use `$MANPATH` directly/literally.
Finally, if both of those are impossible, we can fall back to some
common paths from widely used operating systems.

Note that the `man.conf` parsing has been removed: this is because while
many 'traditional' Unices (BSDs, Solaris, macOS) support this file, only
macOS actually ships a file -- most other Unices use a `conf.d`-style
layout and supporting that from our Python is impractical and silly at
best. On GNU (read: Linux) systems, `mandb` uses `/etc/man_db.conf` with
slightly different syntax and sematics. As this code-path has bitrotted
(and likely never worked, anyway), just remove it.

`create_manpage_completions.py` looks like it has suffered a lot of
confusion and bitrot in general over the last few years -- and is
overdue for a major refactoring. I am quite interested in tackling this,
but I plan to wait until the go-ahead to drop support for Python 2 is
given, as a major refactor/rewrite that still supports Python 2 (and
thus ignores the ergonomic/API/syntax improvements of Python 3) does not
make sense to me.

Related: #5657

It would probably be good to revisit `man.fish` once again when a
comprehensive refactor happens: hopefully every permutation of
`man`/`$MANPATH` could be documented as part of that effort.
@faho
Copy link
Member

faho commented Apr 9, 2020

Note that the man.conf parsing has been removed: this is because while
many 'traditional' Unices (BSDs, Solaris, macOS) support this file, only

The comments tell you where we read this file! For mandoc, typically used on OpenBSD, but also on some linuxen.

Please put it back.

@neersighted
Copy link
Contributor Author

The comments tell you where we read this file! For mandoc, typically used on OpenBSD, but also on some linuxen.

My bad -- didn't realize that codepath was actually reachable since a quick read seemed to indicate it would throw an exception. I've re-implemented the functionality with regex (a lot more readable)... Let me know if this will work for OpenBSD -- I don't have any mandoc or NetBSD systems to test on, sadly.

I was not aware that this codepath was used -- since it appeared that it
would throw an error when it was reached. Redo it, using regex, and
support parsing NetBSD man.conf as well (untested).
@@ -975,6 +974,16 @@ def get_paths_from_man_locations():
# If we can't have the OS interpret $MANPATH, just use it as-is (gulp).
if not parent_paths and os.getenv("MANPATH"):
parent_paths = os.getenv("MANPATH").strip().split(":")
# Fallback: With mandoc (OpenBSD, embedded Linux) and NetBSD man, the only way to get the default manpath is by reading /etc.
Copy link
Member

@faho faho Apr 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, NetBSD man has man -p, as the comment above stated.

Please restore that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NetBSD's man -p actually prints the section directories instead of the manpath directories -- that was my comment that I added, and it was in slight error. We could special-case man -p to take the dirname of each entry -- or we could parse the man.conf file as in https://netbsd.gw.com/cgi-bin/man-cgi?man.conf+5+NetBSD-current

@neersighted neersighted requested a review from faho May 5, 2020 05:19
share/tools/create_manpage_completions.py Show resolved Hide resolved

# Most (GNU, macOS, Haiku) modern implementations of man support being called with `--path`.
# Traditional implementations require a second `manpath` program: examples include FreeBSD and Solaris.
# Prefer an external program first because these programs return a superset of the $MANPATH variable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This prefers the external program by calling both, and only keeping the latter output?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like I missed a break here... It should go on line 979.

@faho faho added this to the fish 3.2.0 milestone May 7, 2020
@faho faho merged commit 02e9486 into fish-shell:master May 7, 2020
@faho
Copy link
Member

faho commented May 7, 2020

Merged, thanks and sorry for the delay!

@neersighted neersighted deleted the create_manpage_completions-manpath branch May 7, 2020 19:09
zanchey added a commit that referenced this pull request May 10, 2020
@zanchey
Copy link
Member

zanchey commented May 10, 2020

Added the extra break in 30a8345

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants