install.sh: curl -o is missing its filename argument, breaking the binary download

[dolph]

Summary

The download step in install.sh is malformed and will not produce the ussher binary it then tries to install.

Location

install.sh (the curl invocation near the top of the file):

curl -L -o https://github.com/dolph/ussher/releases/latest/download/ussher

Problem

curl -o requires the output filename as its argument. As written, -o consumes the URL as the output path, leaving curl with no URL to fetch. The command will either error out or write to a file literally named after the URL, depending on how curl parses the trailing args. Either way, the subsequent install/chmod step that expects a local ussher binary will fail (or, worse, install whatever stale file happens to be in the cwd).

Expected

The flag should either pair -o with an explicit filename:

curl -L -o ussher https://github.com/dolph/ussher/releases/latest/download/ussher

…or use -O to derive the filename from the URL:

curl -LO https://github.com/dolph/ussher/releases/latest/download/ussher

Adding --fail is also worth considering so a 404 doesn't silently produce an HTML error page that then gets chmod +x'd and installed.

Impact

Anyone following the documented install path (curl ... | bash or running install.sh directly) gets a broken install. This is a straightforward release-blocker for new adopters.

[dolph]

Pre-merge CI test plan

The bug is behavioral: curl -L -o <URL> does not produce a file at the path the rest of install.sh expects. The most reliable test is therefore behavioral too — actually run the download step against a local fixture server and assert that a ussher binary file lands where the script then tries to install it from. A pure-grep test would work for this exact typo but would miss the next variant; a behavioral test catches the whole class.

Approach

1. Make the download step testable. Either:
   • (a) Refactor the download URL into an env-var override at the top of install.sh, e.g.

     : "${USSHER_DOWNLOAD_URL:=https://github.com/dolph/ussher/releases/latest/download/ussher}"
     curl -fL -o ussher "$USSHER_DOWNLOAD_URL"

     and have the test point USSHER_DOWNLOAD_URL at a local server. This is the cleanest option and useful beyond CI.
   • (b) Or, in CI, extract just the curl line from install.sh with sed/grep and run it after rewriting the URL. Less invasive but more fragile.
2. Stand up a local HTTP fixture in the runner serving a known small file at a known path.
3. Run the download step against the fixture in a clean working directory.
4. Assert that a file named exactly ussher exists in $PWD, is non-empty, and its bytes match the fixture. This is the assertion the current code fails: with curl -L -o <URL>, no file named ussher is created (curl writes a file literally named after the URL, or errors).
5. Add --fail to the real curl command as part of the fix, so a 404 or HTML error page can never silently get installed and chmod +x'd.

Concrete workflow snippet

Add to .github/workflows/go.yml (or a new install.yml) running on every PR:

  install-script-download:
    name: install.sh download step
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Serve a fake release binary
        run: |
          mkdir -p fixture
          printf 'fake-ussher-binary\n' > fixture/ussher
          ( cd fixture && python3 -m http.server 8080 >/dev/null 2>&1 & )
          # wait for the server
          for i in $(seq 1 20); do
            curl -sf http://127.0.0.1:8080/ussher >/dev/null && break
            sleep 0.2
          done

      - name: Run only the download step from install.sh
        run: |
          set -euo pipefail
          mkdir -p workdir && cd workdir
          # Option (a): env-var override exposed by install.sh
          USSHER_DOWNLOAD_URL=http://127.0.0.1:8080/ussher \
            bash -c 'source <(sed -n "/^# BEGIN download/,/^# END download/p" ../install.sh)'

      - name: Assert a ussher binary was produced
        run: |
          set -euo pipefail
          test -f workdir/ussher || { echo "FAIL: workdir/ussher not created"; ls -la workdir; exit 1; }
          test -s workdir/ussher || { echo "FAIL: workdir/ussher is empty"; exit 1; }
          diff fixture/ussher workdir/ussher
          echo "OK: download step produced ussher with expected contents"

The # BEGIN download / # END download markers would be added around the curl block in install.sh so the test can isolate that step without running the rest of the script (which creates system users, edits sshd_config, restarts sshd — none of which belong in CI).

Belt-and-suspenders: shellcheck

Cheap to add and would have flagged adjacent issues (and may flag this one via SC2154/SC2086 patterns):

  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck install.sh build.sh

shellcheck won't reliably catch curl -o <URL> on its own — curl's flag semantics are domain-specific — so the behavioral job above is the load-bearing test. shellcheck is a useful complement, not a replacement.

What this catches

• The exact current bug: -o consuming the URL → no ussher file in cwd → assertion fails.
• Future regressions where the download "succeeds" but produces an HTML error page (with --fail in the real command, curl exits non-zero; without it, the diff against the fixture catches it).
• Path/filename drift between the curl step and the later install step (e.g. someone changes one but not the other).

What it does not catch

• Issues with the live GitHub release URL (TLS, redirects, asset name changes). That belongs in a separate post-release smoke test, not pre-merge CI, since pre-merge runs shouldn't depend on network state outside the runner.

---

Generated by Claude Code