Re: [PATCH 0/9] Introduce esplit.eclass and port to it

Sam James <[email protected]> Fri, 10 Jul 2026 12:09:49 +0100
Newsgroups gmane.linux.gentoo.devel
Organization Gentoo
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain

Alexander Miller <[email protected]> writes:

> On Thu,  9 Jul 2026 22:22:09 +0100
> Sam James <[email protected]> wrote:
>
>> Introduce a new eclass (esplit.eclass) and port ebuilds to it.
>
> Honestly, I can't see the value provided by that eclass.
> At least for the suggested use case, using `esplit` neither simplifies
> the code nor does it avoid any pitfalls. The same can easily achieved
> with just `printf` and `read` or `mapfile`.

I have no particular stake in esplit existing at all. What I need is for
the sandbox violations to be gone. My initial thinking was to just have
eclass-local helpers to avoid people doing it wrong (as it nearly happened a
few times).

And then it made sense to put it into an eclass rather than copying it
all over the place. That's how I got here rather than having a burning
desire to port everything to this.

If you (or anybody else) would like to propose a series of fixes instead
for that (without something error-prone), it's fine with me.

>
>> This is
>> needed to unblock a Portage release with sandboxing for the 'depend'
>> phase enabled, because the uses of a heredoc replaced here always require a
>> temporary file with < EAPI 9 (and with >= EAPI 9, they do but for large
>> inputs only).
>
> So we need to replace here-strings with process substitution, i.e.,
> use `< <(printf %s "${str}")` instead of `<<< "${str}"`.
> But using `esplit` has no additional benefit here.

Right.

> It may be more interesting when you need NUL-terminated records, yet
> there seem to be no use cases in tree for that.

FWIW, I've only changed global scope use here, so there may be use cases
otherwise, but then, well, why not just use read as they are already.

>
>> +# Suggested use is as follows:
>> +#  mapfile -d '' some_array < <(IFS=... esplit "${str}")
>
> How is that more readable or easier to get right than:
>   IFS=... read -r -d '' -a some_array < <(printf %s "${str}")
> Or, in the common case of a single character as splitter:
>   mapfile -td "${char}" some_array < <(printf %s "${str}")
>

Nobody suggested that and it seems like a reasonable fit now you've said
it. I'll see if anyone can point out a problem with it and mull it over too.

> If you feel we need a helper for this, please provide a better API
> that's simpler to use, something like e.g. `esplit "${str}" some_array`.

Ionen proposed something like this, and I like the idea:

# esplit <arrayname> <string> [IFS]
esplit() {
	mapfile -td '' "$1" < <(
		shopt -o -s noglob
		IFS=${3-$' \t'}
		printf '%s\0' $2
	)
}

esplit array "a b	c"

echo "${array[2]}"

However, it would be more limiting with how it could be used, and what
made me lean away from it was that it'd require documenting it cannot be used
with some variable names, plus nameref-like APIs aren't really common in
Gentoo, and I was wanting to propose this for EAPI 10.

thanks,
sam

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEBBAEWCgCpFiEEJaa7iN2bdkxrVUHCc4QJ9SDfkZAFAmpQ0v4bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyNUE2QkI4OEREOUI3NjRDNkI1NTQx
QzI3Mzg0MDlGNTIwREY5MTkwDxxzYW1AZ2VudG9vLm9yZwAKCRBzhAn1IN+RkMkY
AQCzApqNTyyPSJWxZnkOtDMlrIuUmq9nAaRnzVGe6DN/HAD/VELHAflVOx44IMFi
5wwgYmIVeUIshQ425V95MC68ggY=
=cnKY
-----END PGP SIGNATURE-----
--=-=-=--