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#7632.
If Caps Lock was on, rules that did not specify Caps Lock state were
not matched, for example:
```
+ [K_SLASH] > 'foo'
```
The truth table for matches is:
Event | Rule | Result
---------|-------------|-----------
NCAPS | 0 | match
NCAPS | CAPS | no match
NCAPS | NCAPS | match
CAPS | 0 | match
CAPS | CAPS | match
CAPS | NCAPS | no match
(Internally, Keyman for Mac currently maps 0 to NCAPS on the event for
simplicity.)
The fix is to ignore the Event Caps Lock state if the rule specifies
neither `CAPS` nor `NCAPS`. If the rule specifies either of these
state masks, then the Caps component of the state mask must match.
