Problem
install.sh is the first thing a user runs (curl … | bash), and two ordinary
destination mistakes are reported as something else entirely:
| user mistake | message |
|---|
| folder not writable | Error: failed to download bashunit '0.47.0' from <url> |
| path is a regular file | rm: blocked/bashunit: Not a directory |
Proven not to be a download problem: the same version and URL install fine
into a writable folder in the same session, checksum verified. Only the
destination differs.
The first sends the reader to their network, a proxy, or the version number.
The second never mentions bashunit at all.
Cause
curl writes into the destination with its stderr silenced (2>/dev/null || true, deliberately, so the explicit check below owns the message), and that
check is only [ ! -f "bashunit" ] — which cannot tell "the download failed"
from "the file could not be created here". The rm -f "$DIR"/bashunit on the
line before runs even when $DIR is a file.
Fix
Validate the destination before touching the network: exists-but-not-a-
directory, cannot-create, and not-writable each get their own message naming
the folder and pointing at -d.
Tests use a regular file as the block rather than chmod, because the Bash 3.0
job runs as root where chmod 555 is a no-op; the chmod variant asks the
kernel with [ -w ] and skips itself when the block would not hold.
Problem
install.shis the first thing a user runs (curl … | bash), and two ordinarydestination mistakes are reported as something else entirely:
Error: failed to download bashunit '0.47.0' from <url>rm: blocked/bashunit: Not a directoryProven not to be a download problem: the same version and URL install fine
into a writable folder in the same session, checksum verified. Only the
destination differs.
The first sends the reader to their network, a proxy, or the version number.
The second never mentions bashunit at all.
Cause
curlwrites into the destination with its stderr silenced (2>/dev/null || true, deliberately, so the explicit check below owns the message), and thatcheck is only
[ ! -f "bashunit" ]— which cannot tell "the download failed"from "the file could not be created here". The
rm -f "$DIR"/bashuniton theline before runs even when
$DIRis a file.Fix
Validate the destination before touching the network: exists-but-not-a-
directory, cannot-create, and not-writable each get their own message naming
the folder and pointing at
-d.Tests use a regular file as the block rather than
chmod, because the Bash 3.0job runs as root where
chmod 555is a no-op; thechmodvariant asks thekernel with
[ -w ]and skips itself when the block would not hold.