Locate the limactl executable via os.Args[0] instead of os.Executable()

[jandubois]

We need the symlink directory to find the the ../share/lima directory relative to it. os.Executable() uses /proc/self/exe on Linux and returns the symlink target, which will break things with a Homebrew installation.

This commit also removes the dead code that pretends to resolve any symlinks. It never worked because it called os.Stat() instead of os.Lstat(). If it had worked, then code would have been broken on macOS too.

Alternative implementation to #3564

Fixes #3562

[AkihiroSuda]

#3564 is still better in the robustness; the binary can be executed via an arbitrary path

[jandubois]

#3564 is still better in the robustness; the binary can be executed via an arbitrary path

The only way I can think this can happen is if you invoke limactl via execve and not setup argv[0] (or set it to an incorrect value). Are there others?

That is unfortunate, but I think this is not a reasonable use case; why would anyone do that? If it doesn't work the way they expect, it is really their fault and not ours. I don't even think it would be worth documenting.

[jandubois]

The only way I can think this can happen is if you invoke limactl via execve and not setup argv[0]

Not sure if this is really necessary, but I've added code to fall back on os.Executable() when os.Args[0] is empty, or can't be resolved with exec.LookPath().

If the user intentionally passes the path to a different executable, then I don't consider this an error; the user probably wants to resolve the directory relative to that location.

So the only remaining failure path has 4 preconditions:

• Must pass empty string (or invalid name) for os.Args[0] via execve or similar
• Must be running on Linux
• Must be using Homebrew style symlink setup
• Must require one of the additional guest agents

My facetious response would be: "Welcome to Café Karma! We have no menu; you get what you deserve."

There are many other programs (including all multi-call binaries like busybox) that rely on os.Args[0] to be set correctly, so why can't we?

[jandubois]

Further testing showed that #3564 is not robust either; it only works correctly when the desired lima-additional-guestagents-path is first on the PATH.

I think the Args[0] approach is simpler, more reliable, and enables more functionality (allows locating libexec directory), so should be the one we pick.

[AkihiroSuda]

nit: logrus.WithError.Warn could be used

[AkihiroSuda]

Thanks, let's release v1.1.1 with this and see if it works