The path options are a wibo analogue of winepath(1).

Sorry for the lateness in getting to this. But this kind of thing seems outside the scope of wibo and would better belong in a separate utility ('wibopath').

Would you be willing to make that change?

I would also like to ask, what is the usecase for this kind of tool?
As in, what are you trying to solve? And why implement it inside of wibo from all things?

Yes, happy to make the change to a separate utility.

what are you trying to solve? And why implement it inside of wibo from all things?

When working on a separate change for mwccgap I realized it was assuming/duplicating path behavior for wibo.

The $PATH support reduces some complexity when wrapping wibo in various tools and build systems. Currently it matches how the layout of sotn-decomp, but maybe using something like $WIBOPATH, separate from $PATH makes sense.

I still fail to see what's the benefit of having this behavior inside of wibo.

• Usually you don't have Windows binaries inside your $PATH in Linux machines, so I don't see why check for them in $PATH.
• wibo is mainly used in decomp projects, which tend to pin the versions of the build programs they use, and the usual way to do this is by having those programs inside the project's directories (either committed in tree or gitignored). Global installations in $PATH sounds like a call for disaster on these contexts.

Could you please provide some concrete examples for this $PATH behavior?

I overhauled the module resolution logic and wibo will now resolve binaries by checking different extensions, plus WIBO_PATH, WINEPATH and PATH env vars (since that's how we resolve DLLs as well now). So this should now work! I also went ahead and added wibo path -u and wibo path -w utilities to convert from/to Windows paths, keeping parity with winepath CLI args. Thanks for the PR!