See attached patch; current wording implies each argument is split by the function itself, rather than the reality that IFS splitting is done by the shell- and IFS may not be whitespace chars. I've yet to see an ebuild/eclass relies on the old form, both historically and via scanning the tree 5 minutes ago manually; pkgcore/paludis are implemented this way, portage was till late '06; now it'll accidentally split on a space (meaning has 'ball' 'ball sack' it'll incorrectly return 0 on). Patches for all attached.
Created attachment 279719 [details] rough stab at wording. PMS wording clarification.
Created attachment 279721 [details, diff] portage fix.
(In reply to comment #1) > PMS wording clarification. There's a typo: +\item[has] Return the appropiate code silently.
(In reply to comment #2) > Created attachment 279721 [details, diff] > portage fix. Thanks, that's in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f8504d36c50bef4c1a982a4b9262d3e8e15f438b
Created attachment 279787 [details, diff] follow suit in eclass/tests/ let's follow suit also in eclass/tests/ if this gets passed
(In reply to comment #5) > Created attachment 279787 [details, diff] > follow suit in eclass/tests/ + [[ ${x} == ${needle} ]] && return 0 Shouldn't "${needle}" be double-quoted, to prevent pattern matching?
(In reply to comment #6) > (In reply to comment #5) > > Created attachment 279787 [details, diff] > > follow suit in eclass/tests/ > > + [[ ${x} == ${needle} ]] && return 0 > > Shouldn't "${needle}" be double-quoted, to prevent pattern matching? I believe so. That's why I tweaked the portage patch to use the posix-compiant [ "${x}" = "${needle}" ] form.
Created attachment 279795 [details, diff] Patch for eclass/tests/ as per feedback
(In reply to comment #8) > Created attachment 279795 [details, diff] > Patch for eclass/tests/ > > as per feedback Committed as: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/tests/tests-common.sh?r1=1.3&r2=1.4
(In reply to comment #1) > Created attachment 279719 [details] > rough stab at wording. > > PMS wording clarification. This doesn't look right: +These functions take 2 or more arguments; the second and later arguments are checked to see if they +exactly match the first argument, returning shell true (0) if found, non-zero if not. Calling "has" with only one argument is perfectly valid (in which case the argument is tested against an empty list and the function will return 1).
obviously there is a difference in behavior when talking about something like: has foo "foo bar" but does anyone have any cases where this actually makes a difference ? if not, it seems like sticking with the old wording would be easier ...
Created attachment 736939 [details, diff] pkg-mgr-commands.tex: Update description of text list functions
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=e68df128f8cd3b427168f9a76a655460766e6d70 commit e68df128f8cd3b427168f9a76a655460766e6d70 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-08-31 16:05:08 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-08-31 16:05:08 +0000 pkg-mgr-commands.tex: Update description of text list functions Closes: https://bugs.gentoo.org/374791 Signed-off-by: Ulrich Müller <ulm@gentoo.org> pkg-mgr-commands.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
