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

--7wr4y+T6kQJ81C8g
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 10, 2026 at 12:09:49PM +0100, Sam James wrote:
> Alexander Miller <[email protected]> writes:
>=20
> > 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`.
>=20
> 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 happene=
d a
> few times).
>=20
> 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.
>=20
> 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.
>=20
> >
> >> This is
> >> needed to unblock a Portage release with sandboxing for the 'depend'
> >> phase enabled, because the uses of a heredoc replaced here always requ=
ire a
> >> temporary file with < EAPI 9 (and with >=3D EAPI 9, they do but for la=
rge
> >> 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.
>=20
> Right.
>=20
> > It may be more interesting when you need NUL-terminated records, yet
> > there seem to be no use cases in tree for that.
>=20
> 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.
>=20
> >
> >> +# Suggested use is as follows:
> >> +#  mapfile -d '' some_array < <(IFS=3D... esplit "${str}")
> >
> > How is that more readable or easier to get right than:
> >   IFS=3D... 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}")
> >
>=20
> 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 t=
oo.
>=20
> > 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`.
>=20
> Ionen proposed something like this, and I like the idea:
>=20
> # esplit <arrayname> <string> [IFS]
> esplit() {
> 	mapfile -td '' "$1" < <(
> 		shopt -o -s noglob
> 		IFS=3D${3-$' \t'}
> 		printf '%s\0' $2
> 	)
> }

Formerly just kind of copied the current implementation, but I think
this is better and has no subshells (does need to avoid name clashes
but _esplit_outref is unique enough that I think it does not even
need a mention):

esplit() {
	local -n _esplit_outref=3D$1
	local IFS=3D${3-$' \t'} -
	shopt -o -s noglob
	_esplit_outref=3D($2)
}

>=20
> esplit array "a b	c"
>=20
> echo "${array[2]}"
>=20
> 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.
>=20
> thanks,
> sam



--=20
ionen

--7wr4y+T6kQJ81C8g
Content-Type: application/pgp-signature; name=signature.asc

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

iQFPBAABCAA5FiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmpQ2IgbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJELJEBrCwrEM0t3cH+gMvMIKH4aRizYH5MCbd
OzVVX65/l61PhkkxKWblZMN3pEmLQg9VUuNAYTgt0r4wFSH7qm8JnP+wnnTCRhW6
/tNbmYe/Y754jxWvJfaKB/P+homxrPWni7K3iIAvDICBfofUiozOtZanPnUjCUEj
K232CdUCowjcPGUgWHKWfeuurcyuJLqLKg0eMUlrXGu/Z0jAvIlK9Et5SBORMAOD
FU6Vkqv5zWWJr/oCx+ZBgl6nH7kHrQ+llT4cgbe/Kkvkik2Klk0EBgDpXMfT/79w
hOCjcWajS0/3YP+zJLX7coWpwxXwScz4EUEYo0yUxwxYhpLrfFRvt18nP6ihVJ9m
3aA=
=iK3I
-----END PGP SIGNATURE-----

--7wr4y+T6kQJ81C8g--