Created attachment 360840 [details] ksh-93.ebuild ebuild attached, which supports later alpha and beta snapshots. I've back-ported one fix from the current alpha series as well.
Created attachment 360842 [details, diff] backport fix from ksh93-v
Created attachment 360844 [details, diff] Patch to apply @GENTOO_PORTAGE_EPREFIX@
That's a pretty weird looking ebuild. A few problems? 1. PMS says we support bash-3.2, so associative arrays are not going to fly. 2. Why replace the 1-line sed program with that weird ed loop? 3. I don't understand the FUNCNAME conditional in src_compile.
Created attachment 360846 [details] simplify, remove some debug output
1. PMS says we support bash-3.2, so associative arrays are not going to fly. Oops. That could be replaced by an indexed array, though a hash map would be preferable. Changed in new upload. 2. Why replace the 1-line sed program with that weird ed loop? I typically use ed or ex for in-place file edits. You can use GNU sed if you wish. If you want one line then «ed -s <<<$'...\nw'». The /dev/fd/0 only serves to recycle the existing FD. 3. I don't understand the FUNCNAME conditional in src_compile. IIRC That was attempting to work around the fact that bin/package doesn't appear to return a meaningful exit status. If the build failed, then the ultimate failure would occur during the install phase when portage can't find the binary. I don't think I found a workaround that's any better than checking for existence of the binary. This FUNCNAME logic I usually use to detect direct recursion. Since portage ignores ebuild phase return status, «"$FUNCNAME" || die» allows things like returning from multiple points with nonzero status and catching the return. Here I was using that in conjunction with the RETURN trap. I see there's some other debug stuff I forgot to delete as well. I'll upload a simpler version. The only difference is it will no longer print «sh bin/package results» output.
