only.
In case we are trying to read a catpage, the manpage variable is not defined.
It results in the "cattool" having no arguments.
In case the catpage is compressed, the cattool used is "zcat" which dies if the
standard input is a terminal, meaning the function calling it is exiting as if
there were no ".so"
In case the catpage is uncompressed, the cattool used is "zcat -f" which waits
reading standard input, making the man(1) command hang.
PR: 223560
Reported by: wosch
MFC after: 3 days
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
This reduce the spam a user may face when mandoc tries to
figure out if it can renders a manpage or fallback on groff(1)
Reported by: bdrewery
MFC after: 3 days
longer a special case.
- Prefer PREFIX/share/man over PREFIX/man.
- Add /usr/local/share/man to man_default_path.
- Update manpath man page.
Reviewed by: bapt
The MANPATH environment variable behaviour is documented properly in the manpage
and it now has extended to new feature that allows to make MANPATH env variable
extending the default search path rather than overwriting it making the warning
painful
Reported by: kargl
MFC after: 1 week
mandoc.
If MANPATH begins with a colon, it is appended to the default list; if it ends
with a colon, it is prepended to the default list; or if it contains two
adjacent colons, the standard search path is inserted between the colons. If
none of these conditions are met, it overrides the standard search path.
Import the MANPATH description from mandoc into the man(1) man page
Reported by: kargl
MFC after: 1 week
localbase is not consistent with base for manpages:
/usr/local/man vs /usr/share/man adding share/man allows to fix that
inconsistency and would permit to remove tons of patches/modifications in the
ports tree
If apropos(1) and whatis(1) are not hardlinks to man(1) that means the system is
using mandocdb, then man -k should spawn apropos(1) and/or whatis(1) directly
Reported by: kevlo
Tested by: kevlo
Sponsored by: gandi.net
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
This change among other things improve search capabilities over the manpages
allowing fine grain query.
A new build option WITHOUT_MANDOCDB has been added to keep the ancient version
of the database and the tools. The plan is to entirely remove this option before
11.0-RELEASE.
Differential Revision: https://reviews.freebsd.org/D2603
- Compatiblity with existing manpages has been improved
- Now support ".so" directive with compressed manpages (which fixes a regression
we have since we have new man(1))
man(1) now first test the manpage to run with mandoc to make sure it can be
rendered.
In case groff cannot be found (because base has been built WITHOUT_GROFF) it
recommands to install groff from the packages
in grotty(1). This makes it possible to view colorized manpages in
color.
When MANPAGER environment variable is set, use it instead of PAGER.
Why another environment variable, one might ask? With color output
enabled, both a terminal and a pager should support the ANSI color
escapes. On a supporting terminal, less(1) with option -R would be
such a pager, while "more -s" (the current default pager for man(1))
will show garbage. It means a different default pager is needed when
color output is enabled, but many people have PAGER set customary,
and it's unlikely to support ANSI color escapes, so introducing yet
another variable (MANPAGER) seemed like a good option to me:
- if MANPAGER is set, use that unconditionally;
- if you disable color support (it is by default), and don't set
MANPAGER, you get an old behavior: -P pager, $PAGER, "more -s",
in that order;
- if you enable color support (by setting MANCOLOR), and don't set
MANPAGER, we ignore PAGER which is unlikely to support ANSI color
escapes, and you get: -P pager, "less -Rs", in that order;
- you might have good reasons for different man(1) and general
purpose pagers;
- later versions of GNU man(1) support MANPAGER.
If set to a numeric value, used as the width manpages should be
displayed. Otherwise, if set to a special value ``tty'', and
output is to a terminal, the pages may be displayed over the
whole width of the screen.
Let groff pass the -c flag to grotty, which will turn off ANSI
sequences. While these are not a problem for our more/less, they get
mangled by col(1) and this will result in garbage output.
This makes man(1) work together with textproc/groff, in case the
user decided to delete the old groff from base (-DWITHOUT_GROFF).
Use locale(1) to determine the locale instead of trying to hand roll it.
Correctly construct groff call based on charset and locale independently,
not the mix between the two.
Submitted by: uqs@
