Two bugs in how the Linux/macOS backend decides which VirtualHere binary to
run, both reported by a user whose plugin could not use a client that was
installed and working.
`KNOWN_BINARIES` has listed four architecture variants since the first commit,
but `resolveBinary` only ever returned the first of them. On anything that is
not x86_64 the plugin therefore asked for `vhclientx86_64`, got ENOENT, and told
the operator to install the client they already had. It now probes PATH across
every name and hands back the absolute path it found.
The absolute-path rule was documented in this file and in the README from the
start — "anything else is rejected rather than executed" — and was never
implemented: whatever the operator typed went straight to execFile. So a bare
name silently resolved out of the *runner's* PATH, which is not the PATH of the
shell they tested in and which they cannot see. It is now enforced, and says
which of the two mistakes was made.
Resolution failure is carried to the first send as an ordinary VhIpcError rather
than failing the layer, so the plugin stays up and the Diagnostics tab (and
`doctor`) can render the reason with its remedy — losing the console page that
explains a missing client would be a poor trade for a client that is missing by
default.
Also records, here and in the README, that the `/tmp` FIFOs this backend depends
on were invisible to the plugin runner until punktfunk 0.23.1: the unit set
PrivateTmp=yes, so the binary launched and could never reach the daemon behind
it. That is the shape of the original report — works in a shell, fails from the
plugin, and no config change helps.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
enricobuehlerandClaude Opus 5
1dc5ac9b25