I did consider using the mkdir method for all platforms, simply because then we would be able to not be limited to locking for a single host if the flutter tree is on a file share, but the downside is that if someone kills a running script with kill -9, the flock file descriptor will be closed, whereas the exit trap won't run, leaving a lock directory around.

This is a tradeoff, but I think a file-shared repo is a less common situation than killing a running script on a single host, so I preferred flock where it exists.

I've switched the flock call to be in a loop though, so that we can immediately print the "Waiting for another flutter command..." prompt: as it is now, it doesn't print that until the Dart snapshot is built and runs, so if you don't have it built, it takes a while to say why it's waiting (like 10-20 seconds).

After looking into it some more, I think I'm just going to use the mkdir method on all platforms. I found out that shlock doesn't work on file shares with macOS (I tried it locally, and it says "operation not permitted" when trying to lock), and I tried killing the process with -9, and it still was able to remove the lock directory, and that was the one advantage that I thought flock had over the mkdir method.

The advantage of using mkdir is that it works on network shares and (nearly all) NFS volumes.

I did find after fixing this, though, that the locking that the flutter tools use internally also doesn't work over a network share (at least on an AFP-over-TCP share mounted on a macOS machine), so I'm not sure that this is a real fix to a problem anyone has right now: they already couldn't use Flutter from that kind of share, even if the bash script worked perfectly.

Even more data! :-) Actually, if I kill -9 the subshell that is doing the upgrade, then it will leave around the lock directory, and flock won't (because it's just a file descriptor). Killing the parent shell with kill -9 still allows the subshell to clean up.

So I guess I'm going to leave it using flock for systems that have it. Which is too bad: it made the code a lot simpler to just have one way of doing things.

Even more data! :-) Actually, if I kill -9 the subshell that is doing the upgrade, then it will leave around the lock directory, and flock won't (because it's just a file descriptor). Killing the parent shell with kill -9 still allows the subshell to clean up.

So I guess I'm going to leave it using flock for systems that have it. Which is too bad: it made the code a lot simpler to just have one way of doing things.

We need to link to this PR in the code, lest someone end up going through the whole thing again in a few years :P

Well, the PR is implicitly linked, since it's in the history for the file.

OK, I've updated this to HEAD, and I think this is ready for review "for reals".

Thanks so much for doing this @gspencergoog!