Loaded questions (sorry!):

• Is there an upgrade path if I ran install.sh on a previous version?
  Perhaps this is the responsibility of the distribution's package maintainer? Not sure what guarantees we are responsible for.

• Is this a breaking change?
  Not sure, may depend on 1)

Loaded answers:

• Is there an upgrade path if I ran install.sh on a previous version?
  Perhaps this is the responsibility of the distribution's package maintainer? Not sure what guarantees we are responsible for.

Not directly, no. I think package maintenance tools typically handle cleanup, though I'm not certain. @HRio and @Nebukadneza?

Though I know #50 proposes an uninstall feature, we haven't had one before. If we do want to add one, I can add it (i.e. I think it can be a lot more straightforward than the implementation in #50). And if we're really paranoid, I can push an uninstall feature, release v1.0.2, then merge this (with uninstall updates) and release v1.0.3.

• Is this a breaking change?
  Not sure, may depend on 1)

From the perspective of the public user interface, not at all.

I have to say I fall into the really paranoid camp ;) I like the suggestion to have uninstall before this change, as I think a user could conceivably end up with two bats installations.

I don't mean to make additional work out of nothing though, would welcome others' thoughts.

@mbland agree its the distribution provided package managers job to keep track of files for installed for a specific package and the files in the package (and to handle /etc/ with extra care).

If a user is installing "non packages" they should use stow https://www.gnu.org/software/stow/ or similar.

Uninstall by a script shipped by upstream will always risk being out of sync with the files that are actually installed in the install phase.

One thing that I think should be improved in install.sh shipped with bats-core is to not use cp/mkdir but the install command with a mask, so the umask does not impact the result.

Thanks for the input, @HRio. So @sublimino, are you OK with approving, then?

Also, after this goes in, I'll open another PR to update install.sh to use the install command, then cut v1.0.2.

Screw it, I went ahead and pushed a commit to revamp install.sh. That script keeps getting shorter and cleaner!

@sublimino Mind giving me an official code review approval? (Or @jasonkarns and @btamayo if so inclined.)

./install.sh /usr/local/ works for me.

root@5ea17cbc270d:/bats-core# ./install.sh /usr/local/
Installed Bats to /usr/local//bin/bats
root@5ea17cbc270d:/bats-core# bats
Bats 1.0.1
Usage: bats [-c] [-p | -t] <test> [<test> ...]

LGTM, nice one @mbland

@sublimino Thanks for that, but two things (presented in a spirit of curiosity in search of clarity—not accusation!):

1. I was technically looking for you to click "Files changed", then click "Review changes", then click "Approve" (as in the following image, though the "Approve" option doesn't appear since the PR's already merged):
   

2. Did you merge them locally and then push to master? I was going to click the "Merge" button from the PR myself, or would've expected you to do it that way. Again, it's fine, I was just a little surprised not to see the merge commit here:
   
   or here, which also shows the commits as being unsigned (i.e. lacking the "Verified" badge that you get from setting up a GPG key per https://help.github.com/articles/signing-commits-with-gpg/):
   

Ah! Thanks for mentioning. I see what's happened:

1. I checked out locally and tested without noticing it was in review state in GitHub. Will check more thoroughly next time
2. rebased in the UI, and ofc GitHub only had my public gpg key so I didn't sign the rebase (as would have happened had I done so locally).

GitHub foibles that I'd forgotten about, apologies. To preserve a clean history I wish I could do a signed merge commit locally and force push. Obvious balance of priorities - my preference is gpg signed everything (apologies for the UI rebase from that perspective) but force pushing to a public master is a no-go, so I guess I've forced my own hand on that one. Sorry.

Can't see how to disable rebase in UI on mobile either.

To ensure a chain of trust you could make a contrived commit with the unsigned commit hashes referenced in the commit message. Not ideal but enough for an auditor if that ever occurred?

No worries. I think the v1.0.2 commit I'm about to sign and push should suffice. (I can tell those were my original changes in the "unverified" commits, after all!)

And v1.0.2 is released.