install.sh begins with
set -eo pipefail
cd "$(dirname "$0")"
Piped into a shell, $0 is the shell's own name, so dirname "$0" is . and the script changes to whatever directory the caller happened to be in and runs make there. Nothing tells the user that is what happened.
Reproduction, from inside an unrelated repository:
$ curl -fsSL https://raw.githubusercontent.com/aether-lang-dev/aether/main/install.sh | sh
On macOS, where /bin/sh accepts the options, it gets as far as building:
Fetching latest tags (ensures correct version number)...
Building Aether...
make: *** No rule to make target `compiler'. Stop.
That make ran in the caller's checkout, not in an Aether tree. On Ubuntu it stops earlier, because /bin/sh is dash:
sh: 6: set: Illegal option -o pipefail
curl: (23) Failure writing output to destination
Neither message points at the cause, and the macOS one is the concerning half: a script fetched over the network runs make against a tree it did not come from. In a repository with its own compiler target it would do so silently.
The script's own usage comment only documents ./install.sh, so piping is outside what it promises. It would still be worth either refusing to run when the tree around it is not Aether's, or fetching the tree itself when it cannot find one, so the failure is legible either way. Requiring bash rather than sh would make the Linux half say something useful too.
Found while fixing a CI workflow that installed the toolchain this way; that end is fixed by cloning first and running ./install.sh from inside the clone, which works.
install.shbegins withPiped into a shell,
$0is the shell's own name, sodirname "$0"is.and the script changes to whatever directory the caller happened to be in and runsmakethere. Nothing tells the user that is what happened.Reproduction, from inside an unrelated repository:
On macOS, where
/bin/shaccepts the options, it gets as far as building:That
makeran in the caller's checkout, not in an Aether tree. On Ubuntu it stops earlier, because/bin/shis dash:Neither message points at the cause, and the macOS one is the concerning half: a script fetched over the network runs
makeagainst a tree it did not come from. In a repository with its owncompilertarget it would do so silently.The script's own usage comment only documents
./install.sh, so piping is outside what it promises. It would still be worth either refusing to run when the tree around it is not Aether's, or fetching the tree itself when it cannot find one, so the failure is legible either way. Requiring bash rather thanshwould make the Linux half say something useful too.Found while fixing a CI workflow that installed the toolchain this way; that end is fixed by cloning first and running
./install.shfrom inside the clone, which works.