I really kinda hate how insistent clang-format is to have line
breaks *IFF THE LINE IS TOO LONG*.
Like... lemme just add a break if it looks better, will you?
But it is the style at this time, so we shall tie an onion to our
belt.
* Fix manpath handling in create_manpage_completions.py
...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.
* Restore /etc/man.conf parsing
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).
* Fix create_manpage_completions.py under Python 2
I kinda hate how fussy clang-format is. It reflows text
constantly (line limit), forces things onto one line *except* when
they're too long, and wants to turn this:
```c++
return true;;
```
into this:
```c++
return true;
;
```
instead of, you know, eliminating the second semicolon?
Anyway, it is what it is and we use it, I'll just look into getting some
more slack.
This runs build_tools/style.fish, which runs clang-format on C++, fish_indent on fish and (new) black on python.
If anything is wrong with the formatting, we should fix the tools, but automated formatting is worth it.
Starting with Fedora 30 and RHEL 8, ambiguous python shebangs will now
throw errors during the RPM build process instead of just warnings,
since these systems have moved to Python 3 by default, and Python 2 may
not be available in the future.
See [this
page](https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error)
for more details.
Drop these shebangs as the scripts are only ever called from fish
wrappers.
Specifically closes#4313.
Not being as agressive in what we ignore/blacklist, but can be revisited
easily in the future to add more characters to the argument blacklist.
Haiku only has `man --path`.
Still doesn't support OpenBSD.
Use $MANPATH if available. This needs to:
- Ignore stderr (we pipe it and throw it away)
- Read the subprocess returncode, since `man --path` is an existing
command that fails instead of a non-existent one (that raises an
exception)
- Properly set up the fallback
Fixes#2194.
My previous change to avoid creating a *.pyc file when running
create_manpage_completions.py was wrong because I put the
`sys.dont_write_bytecode = True` on the wrong line. Rather than simply
move that statement make the simpler, cleaner, fix that removes the need
for `eval` where that program is invoked.
The Linux kernel only splits on the first whitespace in the shebang line
(unlike BSD which splits on all whitespace). Which means there can be
only one argument after the path to the program.
Producing man pages is done infrequently (basically just at `make test`
and `make install`) so there isn't any point in writing compiled
byte-code versions of the python modules.
Problem with Type2ManParser
before:
complete -c xcode-select -s h -l help --description 'Prints the usage
message. UNINDENT NDENT 0. 0.'
after:
complete -c xcode-select -s h -l help --description 'Prints the
usage message.'
Don't truncate long lines with " [See Man Page]" suffix - use the
reclaimed 15 characters for more-useful usage info.
Improve the --verbose output with:
- spacing fixes
- diagnostics related to input print repr()/quoted as %r to be less
confusing.
- get rid of stupid name() and use type()/__class__.__name__,
- Always use new-style (new as in post python 2.2) classes so this
behaves the same whether we run in python 2 or 3.
- Properly convert left-quotes and right-quotes to that character in
deroff.py
Currently if there is a conflict with two manpages having the same
name, one completion will override the other. But if one can be parsed
and the other can't the one with parsed results will always have a
higher priority.
It seems smart to only let files be parsed that are clearly
manpage files. Other files wouldn't be openend by man so
I think it is safe to guess that only these files are man
pages.
According to the newer code below:
xdg_data_home = os.getenv('XDG_DATA_HOME', '~/.local/share')
the actual default path is ~/.local/share/fish/generated_completions/
Prefer the standard library lzma module if available. This change prevents
using the backports-lzma when it is installed for a version of Python that
already has the lzma module in its standard library.
Add support for bzip2 and lzma/xz compressed man pages. Support for bzip2 is
part of the Python standard library (at least for 2.7 and >=3.2), while lzma/xz
is only in Python >=3.3; however, there is a backports module for Python 2.7 and
3.2.
