Copy the 'bootstrap' script from the 'build-aux' directory in gnulib
instead of from the 'top' directory. The former one already contains
the 'bootstrap-funclib.sh' code which can then be removed as well here.
Finally, remove the obsolete 'autogen.sh' and 'autopull.sh' scripts.
* autogen.sh: Remove.
* autopull.sh: Remove.
* bootstrap-funclib.sh: Remove.
* bootstrap: Update from 'gnulib/build-aux/bootstrap'.
* Makefile.am (gnulib-sync): Change the source dirsctory of 'bootstrap'
from 'top' to 'build-aux', and remove the copying of above obsolete
files.
NULL is best for C as discussed - for coreutils - at:
https://bugs.gnu.org/66221#53
* bootstrap.conf: Remove dependency on nullptr.
* s/nullptr/NULL/.
This effectively reverts 93ce19f0d5a1.
The sed(1) implementations at least on Solaris and the BSD familiy OSes do
not support the -i flag, and latest POSIX 2024 still does not specify it.
* tests/find/user-group-max.sh: Avoid 'sed -i' by redirecting to
another file ERR2.
This test failed on non-Linux systems:
- On Solaris 11, the output of the native df(1) tool has a different order,
and hence the detection of a usable mount point for the test fails.
Verify that df(1) is from GNU coreutils, or fall back to 'gdf',
else skip the test.
- On a FreeBSD system where /home was a symlink to /usr/home, the code
for finding a usable mount point failed, because the symlink itself
is on the '/' file system.
Ensure that the found mount point is identical to the original test
directory like /home etc.
* tests/find/mount-vs-xdev.sh: Try harder to use a GNU df(1) tool.
Check whether the found mount point is identical to the original
directory name, thus avoiding symlinks.
The .HP macro introduced only recently triggers a 'make check' errors:
env GROFF=groff ../build-aux/man-lint.sh . find.1
check_manpages_format_without_error_messages ( find.1): OK
check_manpages_with_groff_checkstyle_2 ( find.1): FAILED
an.tmac:./find.1:23: style: use of deprecated macro: .HP
make[3]: *** [Makefile:3112: findutils-check-manpages] Error 1
and
env GROFF=groff ../build-aux/man-lint.sh . locate.1 updatedb.1 locatedb.5
check_manpages_format_without_error_messages ( locate.1): OK
check_manpages_format_without_error_messages ( updatedb.1): OK
check_manpages_format_without_error_messages ( locatedb.5): OK
check_manpages_with_groff_checkstyle_2 ( locate.1): FAILED
an.tmac:./locate.1:18: style: use of deprecated macro: .HP
make[3]: *** [Makefile:3287: findutils-check-manpages] Error 1
make[3]: Target 'check-local' not remade because of errors.
The HP hanging paragraph would work nicely, but is marked as deprecated
in groff-1.23; the deprecations warning will disappear in groff-1.24.
Until then, use .TP instead to avoid the check errors.
* find/find.1: Change '.HP' to the '.TP' tagged paragraph macro.
Add a FIXME for 2027 to switch to .HP when groff-1.24 is more commonly
available.
* locate/locate.1: Likewise.
* xargs/xargs.1:
- Migrate from comma-separated to "stacked tag" formatting for command
options. This is easier to read and understand when option syntax is
complex, and eliminates the problem of the comma being misinterpreted.
Setting the comma in bold, not roman, might have increased this risk.
Stacking tags--without direct recourse to formatter requests--however
requires the use of a groff man(7) extension macro, `TQ` (from groff
1.20, 2009). Because this page needs to be portable to non-groff
formatters, define a page-local version after testing for its
nonexistence using other GNU troff extensions (the `do` request and
the `d` conditional expression operator). (Actually, the method here
is to test for `TQ`'s existence and then ignore the macro definition
if the test succeeds; the token `..` terminates whichever eventuates.)
- Use the `TQ` macro to stack paragraph tags presenting synonymous
options to xargs(1).
- Use the page-local `~~` string to put unbreakable spaces (where
supported) between short options and their arguments. (On the other
hand, if a paragraph tag breaks across lines, the document likely
requires revision.)
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* xargs/xargs.1: Consistently use empty request before paragraphing macros
to aid document maintainers. This was already done, inconsistently.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
groff_man(7):
History
M. Douglas McIlroy ⟨m.douglas.mcilroy@dartmouth.edu⟩ designed,
implemented, and documented the AT&T man macros for Unix Version 7
(1979) and employed them to edit Volume 1 of its Programmer’s
Manual, a compilation of all man pages supplied by the system. The
package supported the macros listed in this page not described as
extensions, except P and the deprecated AT and UC. It documented
no registers and defined only R and S strings.
UC appeared in 3BSD (1980). Unix System III (1980) introduced P
and exposed the registers IN and LL, which had been internal to
Seventh Edition Unix man. PWB/Unix 2.0 (1980) added the Tm string.
4BSD (1980) added lq and rq strings. SunOS 2.0 (1985) recognized
C, D, P, and X registers. 4.3BSD (1986) added AT and P. Ninth
Edition Unix (1986) introduced EX and EE. SunOS 4.0 (1988) added
SB. Unix System V (1988) incorporated BSD’s lq and rq strings.
Except for EX/EE, James Clark implemented the foregoing features in
early versions of groff. Later, groff 1.20 (2009) resurrected
EX/EE and originated SY/YS, TQ, MT/ME, and UR/UE. Plan 9 from User
Space’s troff introduced MR in 2020.
* xargs/xargs.1: Favor `P` macro, which the page predominantly uses, over
`PP` (`LP` is not observed). `P` has been universally portable since 1986.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* xargs/xargs.1:
Favor man(7) font macros over *roff font selection escape sequences.
Macros are (a) visually less cluttered, (b) interfere less with spell
checking, and (c), in groff man(7), automatically apply italic
corrections, which otherwise requires explicit use of GNU troff
extension escape sequences (`\/` and `\,`).
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
...not roman.
groff_man_style(7):
Font style macros
...
.I [text]
Set text in an italic or oblique face. Given no argument, I
plants a one‐line input trap; text on the next line, which
can be further formatted with a macro, is set in an italic
or oblique face.
Use italics for file and path names, for environment
variables, for C data types, for enumeration or preprocessor
constants in C, for variant (user‐replaceable) portions of
syntax synopses, for the first occurrence (only) of a
technical concept being introduced, for names of journals
and of literary works longer than an article, and anywhere a
parameter requiring replacement by the user is encountered.
An exception involves variant text in a context already
typeset in italics, such as file or path names with
replaceable components; in such cases, follow the convention
of mathematical typography: set the file or path name in
italics as usual but use roman for the variant part (see IR
and RI below), and italics again in running roman text when
referring to the variant material.
* xargs/xargs.1: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* xargs/xargs.1: Also set the braces in `-I{}` in bold, not roman,
since they are literal.
The `lq` and `rq` strings are widely portable.
groff_man_style(7):
Strings
\*(lq
\*(rq interpolate special character escape sequences for left and
right double‐quotation marks, \(lq and \(rq, respectively.
...
A contemporary man page needs none of the above. \*S is
superfluous; type size changes are invisible on terminals, and
macros that change it restore its original value afterward. Better
alternatives exist for the rest; simply use the \[rg], \[lq],
\[rq], and \[tm] special character escape sequences directly.
Unless you are aiming for a pathological level of portability——
perhaps composing a man page for consumption on simulators of 1980s
Unix systems (or Solaris 10 troff, though even it supports
“\(rg”)——avoid using the above strings.
...
Notes
Some tips on composing and troubleshooting your man pages follow.
...
• When and how should I use quotation marks?
As noted above in subsection “Font style macros”, apply quotation
marks to “brief specimens of literal text, such as article
titles, inline examples, mentions of individual characters or
short strings, and (sub)section headings in man pages”. Multi‐
word literals, such as Unix commands with arguments, when set
inline (as opposed to displayed between EX and EE), should be
quoted to ensure that the boundaries of the literal are clear
even when the material is stripped of font styling by, for
example, copy‐and‐paste operations. groff, Heirloom Doctools
troff, neatroff, and mandoc support all of the special characters
\[oq], \[cq], \[lq], \[rq], \[aq], and \[dq] described in
subsection “Portability” above. DWB, Plan 9, and Solaris 10
troffs do not. Interpolating the strings \*(lq and \*(rq
portably yields directional double quotation marks, if available,
in all these formatters (though neatroff does not supply a man
macro package), but they cannot reliably be used in macro
arguments.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
...for consistency with existing practice in findutils man pages.
* xargs/xargs.1: Set "find" (the command) and "-print0" in bold, not roman.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
Warnings from `groff -C -ww -man` in the forthcoming groff 1.24:
troff:xargs/xargs.1:295: warning: an escaped '~' is not portable to AT&T troff
troff:xargs/xargs.1:296: warning: an escaped '~' is not portable to AT&T troff
troff:xargs/xargs.1:296: warning: an escaped '~' is not portable to AT&T troff
troff:xargs/xargs.1:298: warning: an escaped '~' is not portable to AT&T troff
groff_man_style(1):
Portability
...
\~ Adjustable non‐breaking space. Use this escape sequence
to prevent a break inside a short phrase or between a
numerical quantity and its corresponding unit(s).
Before starting the motor,
set the output speed to\~1.
There are 1,024\~bytes in 1\~KiB.
CSTR\~#8 documents the B\~language.
\~ is a GNU extension also supported by Heirloom Doctools
troff 050915 (September 2005), mandoc 1.9.14
(2009‐11‐16), neatroff (commit 1c6ab0f6e, 2016‐09‐13),
and Plan 9 from User Space troff (commit 93f8143600,
2022‐08‐12), but not by DWB or Solaris 10 troffs.
* xargs/xargs.1:
Define a string to indirect use of `\~` escape sequence. On formatters
that don't support groff extensions, use the AT&T troff `\ `
(backslash-space) escape sequence, which isn't quite as good because it
is a space that is not only unbreakable, but unadjustable--which,
however, doesn't matter when formatting man pages with adjustment
disabled, as some implementations do (and which groff makes
configurable).
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
These instances represent hyphen-minus characters, so should be spelled
in man(7) source as `\-`.
* locate/locatedb.5: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
...not roman, and protect them from hyphenation.
GNU troff, Heirloom Doctools troff, and mandoc all support use of the
`\%` hyphenation control escape sequence at the _beginning_ of a word
suppress its hyphenation. Other troffs do not. Indirect this
application of the escape sequence through a string, interpolating
nothing on formatters that don't advertise GNU compatibility via the
`.g` register. (This means that literals can hyphenate undesirably on
DWB, Solaris, and Plan 9 troffs.)
GNU troff, Heirloom Doctools troff, and mandoc all also support the GNU
`\:` extension to mark break points that should not produce hyphens.
Apply the same technique to avoid undesired formatting of a ':'
character on DWB, Solaris, and Plan 9 troffs.
* find/find.1: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
The `\(lq` and `\(rq` and special character escape sequences are not
universally portable.
Traditionally, AT&T troff did not bother to identify these special
characters at all; it was apparently felt that adjacently setting
directional single quotes sufficed. You can discern this fact in
materials typeset by AT&T troff by observing what one might call
generous kerning of these glyphs when used as "double" quotes.
However, someone at the Berkeley CSRG had a brainwave, and for 4BSD in
1980, added strings named `lq` and `rq` to the man(7) package so that
man pages could access double quotes by whatever means the underlying
implementation had for realizing them. This excellent idea made it into
Unix System V (1988/9), so that every surviving troff implementation
known to me, including DWB and Solaris 10, supports them--save one. The
exception is Plan 9. Fortunately, the Plan 9 from User Space
("plan9port") project accepted a patch from me on 10 October to add
support there as well.[1]
Like the \*" string, \*(lq and \*(rq should not be used in quoted macro
arguments if one desires portability to AT&T troff-descended formatters
(other than Heirloom Doctools troff); if the implementation defines
these strings such that their interpolations contain `"`, undesired
output is the likely result.
[1] https://github.com/9fans/plan9port/pull/735
* find/find.1: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
The `\(en` special character escape sequence is not universally
portable. Indirect it through a string definition.
* find/find.1:
* locate/locate.1:
* locate/locatedb.5:
* locate/updatedb.1:
* xargs/xargs.1: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
An em dash is the more orthographically correct dash for a couple of
contexts where the page had been using an en dash (which denotes a
range), and its special character escape sequence is universally
portable to boot.
* find/find.1: \Replace "(en" by "\(em".
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
When using ` as the Unix shell's command output substitution operator,
use the portable *roff `\(ga` special character escape sequence to
ensure that we really format a grave accent rather than a typographer's
single quotation mark (‘).
* find/find.1: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
The `\(dq` special character escape sequence is not universally
portable. Indirect it through a string definition. (GNU Bash also uses
this technique.[1])
Unfortunately, `"` is one of the worst-behaved and least-accessible
characters in AT&T troff; a pleasant Dr. Jekyll when used on text lines,
its Mr. Hyde persona erupts when used in macro calls, and is wholly
unpredictable to non-experts when appearing in request arguments.[2]
_Some_ AT&T troffs offer `\(dq` on _some_ output devices. AT&T troff
also has no mechanism for a document to define its own special character
escape sequences. GNU troff offers `\(dq` on all output devices.
[1] a8a1c2fac0/doc/bash.1 (L26)
[2] "For the (neutral) double quote, you have recourse to an obscure
syntactical feature of AT&T troff. Because a double quote can begin
a macro argument, the formatter keeps track of whether the current
argument was started thus, and doesn’t require a space after the
double quote that ends it. In the argument list to a macro, a
double quote that isn’t preceded by a space doesn’t start a macro
argument. If not preceded by a double quote that began an argument,
this double quote becomes part of the argument. Furthermore, within
a quoted argument, a pair of adjacent double quotes becomes a
literal double quote."
https://www.gnu.org/software/groff/manual/groff.html.node/Calling-Macros.html
* find/find.1: Do the above.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* find/find.1:
- Use paragraphing macros to put vertical space above and below the
tables (where not already present) so that they looks more like
typographical "displays".[1]
- Simplify "XY" table definition (see groff's tbl(1) man page). This
simpler definition has the same result (and is more adaptable in the
event the text of the table is revised).
- Put horizontal rule below column headings in table that uses them.
- Use thin space escape sequences `\|` between the dots of an ellipsis;
the effect is visible only on typesetting devices.[2] I left the
dummy character escape sequence `\&` trailing it intact, but observe
for the edification of nit-pickers that it has no effect in this
context.[3]
[1] man(7) implementations are historically inconsistent with respect to
whether a `TS` macro call should put any vertical space on the
output, and compositional practices on the part of man page authors
have thus been, to quote Ingo Schwarze, "wildly inconsistent".
https://savannah.gnu.org/bugs/?62841
[2] groff_man_style(7):
Examples of ellipsis usage are shown above, in subsection
“Synopsis macros”. The idiomatic roff ellipsis is three dots
(periods) with thin space escape sequences \| internally
separating them.
[3] tbl(1):
Ordinarily, a table entry is typeset rigidly. It is not filled,
broken, hyphenated, adjusted, or populated with supplemental inter‐
sentence space.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
The man(7) macro package from AT&T troff and most of its descendants,
including those in DWB, Plan 9, and Solaris troffs, support at most six
arguments to any macro call.
* find/find.1: Quote all multi-word arguments to these macros, not just those
in excess of six arguments, as a reminder of defensive practice to document
maintainers.
Before and after on Plan 9 from User Space troff:
$ diff -b -U0 find-plan9port-[12].txt
--- find-plan9port-1.txt 2025-11-18 20:20:08.388887375 -0600
+++ find-plan9port-2.txt 2025-11-18 20:20:14.712881949 -0600
@@ -2068 +2068 @@
- Safer `find -print0 | xargs -0`
+ Safer `find -print0 | xargs -0` approach
@@ -2129 +2129,2 @@
- Traversing the filesystem just once en
+ Traversing the filesystem just once en for 2 different actions
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* locate/locate.1 (HISTORY):
- Use paragraphing macro to put vertical space above the table so that
it looks more like a typographical "display".[1]
- Set table cells that overset the line on AT&T nroff (where the line
length is 65n) using text blocks.
- Issue `na` request in these text blocks to prevent the cell contents
from adjusting in the event the formatter/package/user has configured
man pages to employ adjustment by default. (Practices vary; it's a
long story.[2])
- Remove spaces around the configured tbl(1) tab character of `|`. This
certainly does make the table uglier in source form. Unfortunately,
AT&T tbl(1) takes those spaces deadly seriously and they impact the
computed cell (and therefore column) widths. GNU tbl has for decades
supported a "nospaces" region option to address precisely this
problem; unfortunately it is not portable to DWB 3.3, Plan 9, or
Solaris 10 troffs, and I suspect not to _any_ surviving System V
troff.
Fixes warning from tbl(1) in groff 1.23.0:
locate/locate.1:289: warning: table wider than line length minus indentation
[1] man(7) implementations are historically inconsistent with respect to
whether a `TS` macro call should put any vertical space on the
output, and compositional practices on the part of man page authors
have thus been, to quote Ingo Schwarze, "wildly inconsistent".
https://savannah.gnu.org/bugs/?62841
[2] "Some people do hate adjustment of nroff output, though, which is
why I added a feature to groff man(7) to support disabling it.
The history of this practice is inconsistent. Seventh Edition Unix
(1979) disabled adjustment of man pages when rendering in nroff
mode,[3] and BSD retained that disablement until death. SunOS
commented it as early as SunOS 2.0 (1985), thus restoring adjustment
in nroff mode, and retained that all the way through Solaris 10
(2005). When James Clark wrote groff starting in about 1989, his
man(7) implementation closely emulated SunOS. With the Solaris 11
release in 2010, Oracle discarded its AT&T-descended troff in favor
of the then-current groff release. [That's not quite true--see
below.] They're still on groff 1.22.2 (2013) today, and so they've
been adjusting their man pages in nroff mode for at least 40 years,
as has groff for about 35[]. I don't know what other System V
Unices did."
https://lists.gnu.org/archive/html/groff/2025-05/msg00001.html
(I made an incorrect claim in the foregoing; Solaris 11 still has
its AT&T troff around, but its man page rendering is now performed
by [an old version of] groff.)
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* find/find.1:
* locate/locate.1: Use unbreakable spaces between options and their
arguments, potentially improving legibility.
The existing synopses are short enough that they don't break in such a
way as to promote confusion even on old-fashioned AT&T troffs that use a
line length of 65n in nroff mode (vs. groff man(7)'s historical 78n and
present-day 80n). Thus this change merely makes the synopses robust to
future changes.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* find/find.1:
* locate/locate.1: Use `HP` hanging paragraph macro to indent
non-initial lines of synopsis. Temporarily disable adjustment.
An alternative approach would be to use groff man(7)'s `SY` and `YS`
extension macros; each man page would then need to define local versions
for portability to DWB 3.3, Plan 9, and Solaris 10 troffs.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* find/find.1:
* locate/locate.1: Place thin space escape sequences between ellipsis
dots for more pleasant output when typesetting.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* find/find.1:
* locate/locate.1:
* locate/updatedb.1:
* xargs/xargs.1: Favor man(7) font alternation macros over *roff font
escape sequences. When typesetting with groff(1), the macros
automatically apply italic corrections.
* locate/locate.1: Protect long option name literals from hyphenation.
GNU troff, Heirloom Doctools troff, and mandoc all support use of the
`\%` hyphenation control escape sequence at the _beginning_ of a word
suppress its hyphenation. Other troffs do not. Indirect this
application of the escape sequence through a string, interpolating
nothing on formatters that don't advertise GNU compatibility via the
`.g` register. (This means that literals can hyphenate undesirably on
DWB, Solaris, and Plan 9 troffs.)
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
Before and after, using DWB 3.3 troff (Plan 9 and Solaris 10 troffs are
similar):
$ diff -U0 find.1.dwb-[12].txt|head -n 19
--- find.1.dwb-1.txt 2025-10-13 10:09:17.024054824 -0500
+++ find.1.dwb-2.txt 2025-10-13 10:09:24.764012282 -0500
@@ -2039 +2039 @@
- [bu]
+ o Find files named core in or below the directory /tmp and
@@ -2054 +2053,0 @@
- Find files named core in or below the directory /tmp and
@@ -2064,2 +2063 @@
- [bu]
- Find files named core in or below the directory /tmp and
+ o Find files named core in or below the directory /tmp and
@@ -2080,2 +2078 @@
- [bu]
- Given that another program proggy pre-filters and cre-
+ o Given that another program proggy pre-filters and cre-
@@ -2097,2 +2094 @@
- [bu]
- Run file on every file in or below the current direc-
+ o Run file on every file in or below the current direc-
Further changes in the diff appear because the document now paginates
differently with these troffs. That's because a one-en-wide mark 'o'
(the ASCII representation of a bullet) fits within the 4n space allotted
by the document's `IP` calls, whereas "[bu]" does not.
Fixes warnings from "nroff -C -ww -man" in the forthcoming groff 1.24:
troff:./find/find.1:2260: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2277: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2305: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2326: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2349: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2372: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2392: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2402: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2415: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2431: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2442: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2459: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2471: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2498: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2542: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2597: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2618: warning: an escaped '[' is not portable to AT&T troff
troff:./find/find.1:2630: warning: an escaped '[' is not portable to AT&T troff
* find/find.1: Replace '\[bu]' by '\(bu'.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
* find/find.1:
* xargs/xargs.1: Replace blank lines with empty requests or paragraphing
macro calls as seems to be intended.
* find/find.1: Delete blank lines preceding paragraphing or sectioning
macros that serve only to put excess vertical space in the output.
* locate/locatedb.5: Replace blank lines with a dummy character
producing a blank output line as _might_ be intended.
groff_man_style(7):
? The empty request (.), which does nothing, vertically spaces the
input file for readability by the document maintainer. Do not
put blank (empty) lines in a man page source document. Some
man(1) programs ?squeeze? multiple blank output lines into one.
Fixes style warnings from `groff -rCHECKSTYLE=3 -man`:
an.tmac:/.../share/man/man1/find.1:87: style: blank line in input
...
an.tmac:/.../share/man/man1/xargs.1:231: style: blank line in input
...
an.tmac:/.../share/man/man5/locatedb.5:118: style: blank line in input
...
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
Style warning from `groff -rCHECKSTYLE=3 -man`:
an.tmac:/.../share/man/man1/find.1:9: style: 1 leading space(s) on input line
* find/find.1 (SYNOPSIS): Make an intended empty request work that way.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
Style warnings from `groff -rCHECKSTYLE=3 -man`.
an.tmac:/.../share/man/man1/locate.1:1: style: .TH missing third argument; \
consider document modification date in ISO 8601 format (YYYY-MM-DD)
an.tmac:/.../share/man/man1/locate.1:1: style: .TH missing fourth argument; \
consider package/project name and version (e.g., "groff 1.23.0")
...and similar.
groff_man_style(7):
.TH identifier section [footer‐middle [footer‐inside [header‐
middle]]]
...
By convention, footer‐middle is the date of the most recent
modification to the man page source document, and footer‐
inside is the name and version or release of the project
providing it.
* find/find.1:
* locate/locate.1:
* locate/locatedb.5:
* locate/updatedb.1:
* xargs/xargs.1: Add appropriate third and fourth arguments to `TH` macro calls.
To determine the revision date to include in the page, I used the Git
"AuthorDate" of the last commit consituting anything but a "bump" to the
copyright notice.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
Plan 9 and Solaris tbl, like Seventh Edition Unix tbl, do not support
the 'x' column modifier. This extension appeared in DWB tbl by version
3.3 and early in GNU troff development (both circa 1990). I suspect,
but do not know, that other System V Unix tbl programs don't support it
either.
These old tbl programs are brutal when they encounter an unsupported
column modifier--they abort the preprocessor altogether ("tbl quits")
without attempting recovery.[1] Because tbl works as a filter, like
eqn, pic, soelim, or more familiar Unix tools (cat, sed, nl), this means
that tbl truncated the entire remainder of the input at that point. GNU
tbl is more robust, and discards input only until the next `.TE` token.
Due to this rudeness it's impossible to portably use 'x' without
rewriting the page text, and I know of no good way to parameterize a
table format. (tbl(1) doesn't have variables or anything like a macro
preprocessor. *roff strings are no use because tbl is a _pre_processor
for troff.)
To portably use 'x' requires a man page to test the underlying
implementation and potentially rewrite the page prior to installing it.
See a recent patch of mine to ncurses (merged in its 20251115 release)
for an approach potentially adaptable to findutils.
https://lists.gnu.org/archive/html/bug-ncurses/2025-11/msg00035.html
[1] I've proposed a merge request to Plan 9 from User Space to make its
tbl less intolerant. Even if accepted, that won't help anyone who
uses other "legacy" troffs.
https://github.com/9fans/plan9port/pull/739
* find/find.1 (Functional Changes): Drop 'x' table modifier.
Discussed at:
https://lists.gnu.org/r/bug-findutils/2025-11/msg00094.html
Copyright-paperwork-exempt: Yes
Add some more tests exercising bind mounts on the same device which
should not be affected by -mount or -xdev, and tests with a loopback
file system and a bind mount from there.
* tests/find/mount-vs-xdev-bind.sh: Add test.
* tests/find/mount-vs-xdev-other-fs.sh: Likewise.
* tests/local.mk (all_root_tests): Reference them.
