bin/fleet does not resolve symlinks; CLI broken when invoked via ~/.local/bin/fleet

[wrsfmss]

Summary

bin/fleet line 25 computes FLEET_ROOT from ${BASH_SOURCE[0]} without resolving symlinks. After fleet init creates the standard symlink at ~/.local/bin/fleet (as documented in _meta.json and the README), invoking fleet via PATH fails because FLEET_ROOT resolves to ~/.local instead of the install root, and the subsequent source "$FLEET_ROOT/lib/core/config.sh" cannot find the file.

Reproduction (v3.0.4 on macOS)

git clone https://github.com/oguzhnatly/fleet.git ~/.local/share/fleet
~/.local/share/fleet/bin/fleet init     # creates ~/.local/bin/fleet symlink — works
fleet --version                          # FAILS

Output:

/Users/.../.local/bin/fleet: line 28: /Users/.../.local/lib/core/config.sh: No such file or directory

All subsequent commands (fleet agents, fleet health, etc.) fail the same way until the script is invoked via its absolute path or patched.

Root cause

bin/fleet:25:

FLEET_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"

When ${BASH_SOURCE[0]} is the symlink at ~/.local/bin/fleet, dirname returns ~/.local/bin, and .. resolves to ~/.local instead of the repo root.

Proposed fix

Wrap ${BASH_SOURCE[0]} in realpath so the symlink is resolved before computing the parent:

FLEET_ROOT="$(cd "$(dirname "$(realpath "${BASH_SOURCE[0]}")")/.." && pwd)"

realpath is already used at line 17 of the same file, so it's a safe assumption on supported platforms.

PR incoming.