[PATCH v2 1/2] rpmatch.3: clarify first-character-only FUD

наб
2021-10-02T12:18:50Z

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

It's plain not true as-written ‒ locales can and do provide longer matches
(Aramaic has a "አዎን" alternative, for example) ‒ but it's important to
note that (a) this may be an issue and (b) nonetheless this is the right
way to process this

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
This should resolve both the unnecessary FUD and the doubts it would
raise, while preserving the note. I'm not sure I'd agree with C locale
being the most important one (I'd put that burden on "the current one"),
but it's mentioned here because English locales (and most other ones for
YESEXPR/NOEXPR) derive from it.

man3/rpmatch.3 | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/man3/rpmatch.3 b/man3/rpmatch.3
index 846c492b7..1f9732e3f 100644
--- a/man3/rpmatch.3
+++ b/man3/rpmatch.3
@@ -125,19 +125,15 @@ is available on a few other systems.
.\" It is available on at least AIX 5.1 and FreeBSD 6.0.
.SH BUGS
The
-.BR rpmatch ()
-implementation looks at only the first character
-of
+.BR YESEXPR " and " NOEXPR
+of some locales (including "C") only inspect the first character of the
.IR response .
-As a consequence, "nyes" returns 0, and
-"ynever; not in a million years" returns 1.
-It would be preferable to accept input strings much more
-strictly, for example (using the extended regular
-expression notation described in
-.BR regex (7)):
-.B \(ha([yY]|yes|YES)$
-and
-.BR \(ha([nN]|no|NO)$ .
+This can mean that "yno" et al. resolve to
+.BR 1 .
+This is an unfortunate historical side-effect which should be fixed in time
+with proper localisation, and should not deter from
+.BR rpmatch ()
+being the proper way to distinguish between binary answers.
.SH EXAMPLES
The following program displays the results when
.BR rpmatch ()
--
2.20.1