problem(s) with extractbb and extractbb.lua recently introduced

[Max Chernoff]

Hi Frank,

On Mon, 2024-07-08 at 12:48 +0200, frank.mittelbacha wrote:
> we load not a full set of packages and while extractbb comes with
> the platform binary the necessary new wrapper is not installed as part
> of that but in texlive-scripts-extra which we hadn't any need to load
> before. Is that intended?

Yes--extractbb.lua is maintained separate from dvipdfmx, and
"texlive-scripts" only contains core infrastructure scripts. But for the
"dvipdfmx" package, I added

    depend texlive-scripts-extra

so this should be getting installed automatically. It clearly isn't
though, so I'm not sure what's going wrong here.

> When I run the testsuite locally it also fails on that test, but on my
> system (Mac) it is not the case that extractbb is fully missing. However
> it seems to be unable to find a necessary lua script, e.g.
>
> ~/GitHub/latex2e/base @ Franks-Air(frankmittelbach): extractbb --version
> ! ERROR (extractbb.lua): The script is in an incorrect location:
> /Library/TeX/texbin
> stack traceback:
> 	/Library/TeX/texbin/extractbb:189: in main chunk
>
> [...]
>
> however, on my Mac I have the full distribution and extractbb.lua is in
>
> /usr/local/texlive/2024/texmf-dist/scripts/texlive
>
> [...]
>
> So it looks as if there is one or more packaging issues (or some coding
> issue in the lua file from Max in the case of MacOS) that were
> introduced fairly recently, i.e, when extractbb.lua got added.

Yeah, this is probably my fault, although I'm not exactly sure what's
going wrong. For the wrapper command to run correctly, it needs to be
located either in the same directory as the LuaTeX binary or somewhere
in the scripts tree. What do you get when you run the below?

    $ dirname $(type -p luatex)
    $ dirname $(type -p extractbb)

    $ kpsewhich --format=texmfscripts extractbb.lua
    $ realpath $(type -p extractbb)

If either the first two commands OR the last two commands give identical
output, then the script should run properly; if both pairs give
different output, then the script will refuse to run with the error
message that you're seeing.

I assumed that all Unixes would behave the same way, so we only tested
with Linux and Windows before deploying the new script. macOS seems to
be different than Linux here, so once I figure out _how_ it's different,
I should be able to adjust the script fairly easily.

Thanks,
-- Max