Search for the data directory using argv[0] *and* os.Executable()

[refi64]

Some version managers like aqua rely on shims in $PATH to run the proper application. This isn't particularly unusual, but it was broken by the changes in #3566, because directory lookup ends up pointing to the shim rather than the underlying installation.

The existing logic already has the concept of falling back to os.Executable if a path based on argv[0] can't be determined, so this issue can be solved by just always checking os.Executable in addition to argv[0].

[refi64]

IMPORTANT NOTE: I have not actually tested this via homebrew, so someone who uses it should test this 😅

[jandubois]

Please fix the linter errors (no naked returns).

I think the Godoc comment should also be updated to explain the additional stat test.

I haven't tested the code with homebrew on Linux either, but it looks fine to me.

And I'm curious: isn't this working around a bug in the shim? Shouldn't the shim update arg[0] before exec'ing the correct command?

[refi64]

And I'm curious: isn't this working around a bug in the shim? Shouldn't the shim update arg[0] before exec'ing the correct command?

This is all a bit weird for sure, but it's not particularly unusual, e.g. login shells are run with argv[0] == "sh" regardless of what the actual name is. Somewhat cursed, but I mean, this is unix, it's all a bit cursed.

that being said! this made me step back and reevaluate the approach, and I realized there's a conceptually cleaner way of handling this: just always look for the directory to check based on both argv[0] and os.Executable. It already falls back to the latter if the former is unavailable, so the logic isn't much of a stretch, and it's all thus a bit neater anyway. (in retrospect maybe that should've just been a second PR instead of me resolving everything and editing the PR title/description, oops.)