I pushed the attached simple patch to fix this.
From e549900aa62dde81c65af5ede950a7918a0facb5 Mon Sep 17 00:00:00 2001
From: James Youngman <ja...@youngman.org>
Date: Fri, 17 May 2024 08:42:07 +0100
Subject: [PATCH] [doc] Use @var{name}, not NAME or @var{NAME} in "Hard Links".
To: findutils-patc...@gnu.org
The @var{name} renders as NAME in Info, to this inconsistency is hard
to spot there. The inconsistency is easier to spot in the typeset
output (e.g. PDF, Postscript).
Our solution is to use @var{name} even inside @samp, since that
works (and is intended to, according to the documentation).
This fixes Savannah bug #65305.
---
doc/find.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/find.texi b/doc/find.texi
index f6b52047..2e543085 100644
--- a/doc/find.texi
+++ b/doc/find.texi
@@ -867,9 +867,9 @@ find . -lname '*sysdep.c'
Hard links allow more than one name to refer to the same file on a
file system, i.e., to the same inode. To find all the names which refer
-to the same file as @var{name}, use @samp{-samefile NAME}.
+to the same file as @var{name}, use @samp{-samefile @var{name}}.
-@deffn Test -samefile NAME
+@deffn Test -samefile @var{name}
True if the file is a hard link to the same inode as @var{name}.
This implies that @var{name} and the file reside on the same file system,
i.e., they have the same device number.
@@ -882,7 +882,7 @@ so this can cut down on needless searching.
If the @samp{-L} option is in effect, then dereferencing of symbolic links
applies both to the @var{name} argument of the @samp{-samefile} primary and
to each file examined during the traversal of the directory hierarchy.
-Therefore, @samp{find -L -samefile NAME} will find both hard links and
+Therefore, @samp{find -L -samefile @var{name}} will find both hard links and
symbolic links pointing to the file referenced by @var{name}.
@end deffn
--
2.39.2
