steps

# on a fresh install, i.e.
#   rm -rf ~/.sbt/ ~/.cache/
# and with curl in path:
SBT_LAUNCH_REPO=https://www.google.com/nope ../sbt -d ""

problem

Typical situation: we have a private Artifactory, or other local caching server we need to pull dependencies through, or we have the HTTP proxy vars set incorrectly for whatever reason, or as in the example, the $SBT_LAUNCH_REPO value is simply set incorrectly:

Bootstrapping fails and then subsequent invocation of sbt fail immediately because some HTML body e.g. "404 Not Found" was written to the the boot-jarfile:

Error: Invalid or corrupt jarfile /root/.cache/sbt/boot/sbt-launch/1.5.5/sbt-launch-1.5.5.jar

expectation

sbt should detect and cleanup any failed download, not leaveing the system in a state where we are unable to launch sbt again.

notes

This should be fixable by asking curl to exit with fail with non-zero exit code, and checking $? instead of just testing -f.

(man curl)
...
       -f, --fail
              (HTTP) Fail silently (no output at all) on server errors. This is mostly done to better enable
              scripts  etc to better deal with failed attempts. In normal cases when an HTTP server fails to
              deliver a document, it returns an HTML document stating so (which often also describes why and
              more). This flag will prevent curl from outputting that and return error 22.

              This  method is not fail-safe and there are occasions where non-successful response codes will
              slip through, especially when authentication is involved (response codes 401 and 407).

I have yet to test how this works It fails in a similar fashion when wget is the only client available, but I believe wget at least already considers HTTP errors, and exits with non-zero. But it needs to be checked for.