Tidy shell scripts in ./bin

[IsaacG]

• Prefer [[ over [
• Expand tabs to 4 spaces
• Quote variables uniformly in "${var}" format
• Use local for function variables
• Prefer lowercase variable names for non-readonly variables
• Replace let with $((

[ee7]

Big improvement - thanks.

I've checked that, with this PR, shellcheck no longer complains:

$ git rev-parse --short HEAD
d74bb32c
$ shellcheck --version
ShellCheck - shell script analysis tool
version: 0.9.0
license: GNU General Public License, version 3
website: https://www.shellcheck.net
$ shellcheck bin/check_required_files_present bin/fetch-configlet bin/reorder-keys && echo 'success'
success

I hadn't realized that the fetch-configlet script in this repo is so outdated. I'll PR to update it. It should use this version, like the track repos do.

Edit: I've created #2259. I'm happy for us to merge this PR as-is first, then rebase #2259 on top. But feel free to drop the fetch-configlet changes from this PR if you prefer. I wouldn't bother.

I've also intended to add shellcheck to CI in this repo, but apparently I never got around to it. I have it in Exercism repos that I maintain.

[glennj]

Is exit "$(( missing_files == 0 ))" too obscure?

[IsaacG]

I'd prefer (( missing_files == 0 )); exit ... but being verbose here is probably good. It's longer but less likely to give anyone pause.

[IsaacG]

I'm quite happy letting the other PRs land first and rebasing this.

[IsaacG]

Rebased and I took a second pass.

[ee7]

LGTM, with some formatting suggestions.

I've checked that shellcheck is still happy.

Non-blocking comments:

• As a later follow-up, I would support renaming bin/check_required_files_present to bin/check-required-files-present, to match bin/reorder-keys.
• Again as a later follow-up, I'd probably support a PR that adds a script formatting check to CI. Something like: shfmt -i 4 -ci -sr -kp. Or whatever.
• There's maybe a slight precedent for preferring to indent bash scripts with 2 spaces: that's what the fetch-configlet script (now) uses in this repo, and in every track repo. But that script will probably be removed from this repo, and I don't mind either way.