If you ran curl -fsSL https://keating.help/install | bash and then typed keating, you got a confusing "No such file or directory" error. The installer reported success — it downloaded, extracted, and linked — but the resulting binary could not run. Two independent bugs caused this.
What Was Broken
The GitHub Actions release workflow archived the bundle contents without a top-level versioned directory. The install script extracted the tarball into ~/.local/share/keating/ and expected a subdirectory called keating-0.3.3-linux-x64/, but the files landed directly in the parent directory. On top of that, the wrapper script at ~/.local/bin/keating tried to exec a standalone binary called keating — but the tarball contains a Node.js project where the real entry point is bin/keating.js.
Tarball Structure Fix
The release workflow now stages all bundle files inside a versioned keating-VERSION-OS-ARCH/ directory before running tar. This means the tarball root iskeating-0.3.5-linux-x64/, which matches the path the install script constructs and expects.
# Before (broken): tar archived bundle contents flat tar -czf "${BUNDLE_NAME}.tar.gz" -C bundle . # After (fixed): tar archives the versioned directory tar -czf "${BUNDLE_NAME}.tar.gz" "${STAGE_DIR}"
Node.js Entry Point Fix
The install wrapper now launches Keating through Node.js instead of trying to exec a standalone binary:
# Before (broken): exec "$INSTALL_APP_DIR/$bundle_name/keating" "$@" # After (fixed): exec node "$INSTALL_APP_DIR/$bundle_name/bin/keating.js" "$@"
Early Node.js Check
The install script now checks for node alongside tar andmktemp. If Node.js is not on PATH, the installer exits immediately with a clear message instead of waiting until runtime to discover the missing dependency.
Reinstall with the updated script to get a working binary: curl -fsSL https://keating.help/install | bash