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

--tBxgfs/9SrxiUeQi
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 10, 2026 at 07:33:28AM -0400, Ionen Wolkens wrote:
> 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 happe=
ned 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 re=
quire a
> > >> temporary file with < EAPI 9 (and with >=3D 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.
> >=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=
 too.
> >=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_arra=
y`.
> >=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
> > 	)
> > }
>=20
> 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):
>=20
> esplit() {
> 	local -n _esplit_outref=3D$1
> 	local IFS=3D${3-$' \t'} -
> 	shopt -o -s noglob
> 	_esplit_outref=3D($2)
> }

=2E.. not to say that we should actually do this, just throwing it there.

Given the minimal usage in global scope I do tend to feel we may be
better off just copying something simple rather than do an eclass.

>=20
> >=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 b=
e 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
>=20
>=20
> --=20
> ionen



--=20
ionen

--tBxgfs/9SrxiUeQi
Content-Type: application/pgp-signature; name=signature.asc

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

iQFPBAABCAA5FiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmpQ3ykbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJELJEBrCwrEM0wvsH/jNlWDnHU6qV7UCrvMFZ
CL92Oox9ttIMrwrDH1x8RM/Pr3OdXs3b1fyfGQsQoROOGXWgaYLdobiMpiySUAIZ
5Eb6gp9srWGKTW8FBdReEROPGvLUpnuaDZo5wc6QIhcXRHigkPQirqKQr2mDng1w
NOB9B/An8Lpzy5KKh/e5jvYdyr4AeLvn2h1mX6t4TcS9zerKwNCHbBxBRJzW5k8/
c/Q5JGitP0+i36f6u5TBNmQcu7LnRMssvQNNEHU54F05UoBEaRgpfxi1tEVWsvRY
Cxshc6bjUuCKyPDZ4yj3+T0iC0cBQL7e5RgTIFZYLENme25oBeZZ3RUvg4oF+7TB
7A4=
=ziC8
-----END PGP SIGNATURE-----

--tBxgfs/9SrxiUeQi--