Problem
All three destination errors in install.sh end with the same advice:
Error: 'blocker' exists and is not a directory.
Choose another destination with -d, or remove that file.
There is no -d flag. The script parses positional arguments only ([dir] and [version], in either order), which is what docs/installation.md documents. Following the advice literally fails:
$ bash install.sh -d somewhere
Invalid arguments. Expected version or directory.
So a user who hits a blocked destination is sent to a form that errors differently, from the one message whose whole job is to tell them how to recover.
Affects install.sh:202, :208 and :214 — the not-a-directory, cannot-create and not-writable branches, all added in #1197.
Why it slipped through
tests/acceptance/install_test.sh asserts the diagnosis line only (is not a directory, cannot write to) and never the remedy line, so the invented flag was never executed.
Suggested fix
Name the real interface, and have the test run the suggested form rather than string-match it — an advice line that is asserted but never executed is how this happened in the first place.
Secondary: a local install.sh installs next to itself, not in your cwd
install.sh:192 does cd "$(dirname "$0")" before resolving $DIR. Under the documented curl … | bash, $0 is bash and dirname gives ., so it lands in the caller's directory as intended. Running a local copy by path does something else:
$ cd /tmp/somewhere && bash /path/to/repo/install.sh out
> bashunit has been installed in the 'out' folder
$ ls out
ls: out: No such file or directory # it is at /path/to/repo/out
The message names a relative folder that does not exist relative to the user. Not changing this here — action.yml, release.sh and the gh-pages workflow all consume the script and the behaviour may be load-bearing for them — but it is worth a decision.
Problem
All three destination errors in
install.shend with the same advice:There is no
-dflag. The script parses positional arguments only ([dir]and[version], in either order), which is whatdocs/installation.mddocuments. Following the advice literally fails:So a user who hits a blocked destination is sent to a form that errors differently, from the one message whose whole job is to tell them how to recover.
Affects
install.sh:202,:208and:214— the not-a-directory, cannot-create and not-writable branches, all added in #1197.Why it slipped through
tests/acceptance/install_test.shasserts the diagnosis line only (is not a directory,cannot write to) and never the remedy line, so the invented flag was never executed.Suggested fix
Name the real interface, and have the test run the suggested form rather than string-match it — an advice line that is asserted but never executed is how this happened in the first place.
Secondary: a local
install.shinstalls next to itself, not in your cwdinstall.sh:192doescd "$(dirname "$0")"before resolving$DIR. Under the documentedcurl … | bash,$0isbashanddirnamegives., so it lands in the caller's directory as intended. Running a local copy by path does something else:The message names a relative folder that does not exist relative to the user. Not changing this here —
action.yml,release.shand the gh-pages workflow all consume the script and the behaviour may be load-bearing for them — but it is worth a decision.