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@xxxxxxxxxxxxxxxxxx> --- 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
Attachment:
signature.asc
Description: PGP signature
