I WTF'ed on this for a long time before I noticed that the docs for "has" were sort-of contained in "hasv". Might as well give "has" its own.
>From 423123cc2ea429c06914ef858a6fdb86c0c6d30b Mon Sep 17 00:00:00 2001 From: Michael Orlitzky <m...@gentoo.org> Date: Wed, 22 Jan 2014 16:18:23 -0500 Subject: [PATCH] Add the "has" function to the ebuild(5) man page.
--- man/ebuild.5 | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/man/ebuild.5 b/man/ebuild.5 index 524006a..36836b3 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -1049,6 +1049,14 @@ of \fI\-\-without\-\fR. Beginning with \fBEAPI 4\fR, an empty \fIconfigure opt\fR argument is recognized. In \fBEAPI 3\fR and earlier, an empty \fIconfigure opt\fR argument is treated as if it weren't provided. .TP +.B has\fR \fI<item>\fR \fI<item list> +If \fIitem\fR is in \fIitem list\fR, then \fBhas\fR returns +0. Otherwise, 1 is returned. There is another version, \fBhasv\fR, that +will conditionally echo \fIitem\fR. +.br +The \fIitem list\fR is delimited by the \fIIFS\fR variable. This variable +has a default value of ' ', or a space. It is a \fBbash\fR(1) setting. +.TP .B hasv\fR \fI<item>\fR \fI<item list> If \fIitem\fR is in \fIitem list\fR, then \fIitem\fR is echoed and \fBhasv\fR returns 0. Otherwise, nothing is echoed and 1 is returned. As indicated with -- 1.8.3.2
