Fixes#10200.
This is a two-part fix. First, with our normal `set -e` build
environment, the existing loop never ran more than once, so the 5
second delay pattern we used to use in the dim dark past was no longer
being applied. It is likely that in most cases, this will address the
failure to detach.
The second part is to escalate our detach with a `-force` parameter,
after 5 failed polite attempts. This is new and is addressing the
suggestion in #10200, so we'll have to see if it has any impact on
build stability.
Because we don't know if mac BSD cp or GNU cp will be first on the path,
where there is ambiguity (e.g. with -R flag), we will use the macOS cp
command in /bin to ensure that we have consistent results. The
alternative would be to fixup each instance of the cp parameters so that
they work consistently with either cp command, but given these scripts
can run only on macOS, that seems unnecessary.
This replaces the earlier change in 97c6331b5.
Fixes#8533 after build agent maintenance put GNU coreutils cp on path
ahead of macOS /bin/cp. This subtly changed the behaviour of the `-R`
flag such that it copied the folder into a subfolder rather than copying
the contents of the folder into the destination folder:
Original layout:
```
Install Keyman.app/Contents/MacOS/
applet
textinputsource
Keyman.app/
```
Corrupted layout:
```
Install Keyman.app/Install Keyman.app/Contents/MacOS/
applet
textinputsource
Keyman.app/
```
Query: should we be rolling back the path changes so that /bin is first
on the path? I am concerned about other subtle changes in behaviour in
the macOS and iOS builds. Otherwise it feels like we may need to audit
the scripts in /mac, /ios (and possibly /common, /core, /web,
/resources) for potential changes.
Annoyed that it took me so long. Also annoying that macOS fails so
subtly when a parent folder has the .app extension in its name.
Fixes up scripts (except under /linux) to use `#!/usr/bin/env bash`
instead of `#!/bin/bash` or `#!/bin/sh` so that we don't end up with
the ancient version of bash supplied with macOS.
This became urgent with this PR, because of bash-4.xisms in
build-utils.sh, for example on line 572:
```
if [[ -v _builder_params[$e] ]]; then
```
When working on a new build script, I tripped over the `-?` question
mark help parameter here, as it needs to be escaped. Opted to fix all
the instances in our scripts, although AFAICT there would not have been
current bugs arising from this, as there were no conflicting one
character options lower in the case list.
First steps towards a clean install script
for Keyman for Mac. Some steps still out-
of-order for now, particularly opening
System Preferences to allow Keyman before
Keyman has run for first time.
