Fix compatibility issue with 'cp' command in shell script.

[sebastiancarlos]

Summary:

This change addresses a compatibility issue arising from the use of the macOS-specific -X flag in the cp command withing a shell script called during the npm run ios command.

The -X flag prevents the copying of Extended Attributes and resource forks, which indeed prevents possible issues on macOS. However the flag is not supported by GNU's cp, commonly installed via homebrew on macOS systems, and usually added to the user's PATH.

This fix basically does a feature test to figure out if the -X flag is available, and only uses it is the test is positive.

The intended behavior of not copying Extended Attributes and resources forks is still preserved in the script even if GNU's cp is in the path, as GNU's cp doesn't copy these by default.

In short, the script will behave correctly regardless of the cp version installed, but the script will now be more POSIX compatible.

The fix helps prevent unnecessary debugging time as, in my experience, the source of this error is not always displayed in the output of npm run ios.

As mentioned in:

• 0.73.1 iOS build failed on Apple Silicon Mac(M1 Pro), but I can do build on 0.72.8 version of React Native #42112 (comment)
• Running first init project Error React-rncore: Command PhaseScriptExecution failed with a nonzero exit code #39734 (comment)

Relevant Documentation

• GNU's cp documentation
• macOS's cp man page

Changelog:

[IOS] [FIXED] - Fix compatibility issue with 'cp' command in shell script.

Test Plan:

# with GNU's cp in path
npm run ios
# observe build passing (this is the fix)

# remove GNU's cp from path
npm run ios
# observe build passing (no regression)

[facebook-github-bot]

Hi @sebastiancarlos!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	17,885,653	+4,104
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	21,240,052	+21
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: 8ff05b5
Branch: main

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[felixmueller-cnnctvstn]

Is there a tmp fix for that?

[huntie]

Thanks for this change! 🙂

Can we test by [[ "$OSTYPE" == "darwin"* ]] instead? I appreciate this does direct feature detection, but would prefer if we avoided the file system side effects.

[sebastiancarlos]

Hi @huntie. I agree that a way of feature detection without file systems side effect is desireable.

Can we test by [[ "$OSTYPE" == "darwin"* ]] instead?

Unfortunately the OSTYPE detection is not enough, as it identifies the OS but not the specific implementation of cp that's being used. The problem can happen when the OS is Darwin and the cp command in the PATH does not support the -X flag (e.g. GNU's cp).

The use of temporary files test was chosen since macOS's native cp does not provide a --help or --version command to use instead. It does print its usage on wrong input, but it also emits a non-zero exit code, which is a problem because script_phases.sh has pipefail set.

In short, making another test is a bit convoluted and I'm not sure if I have the bandwidth to come up with a working solution for that.

[huntie]

I think perhaps we can replace this with the EdenFS detection we use in Codegen's build.sh — this way it's more clear why we are applying this flag against a bulk copy.

I'm happy to test this once imported.

    # Detect if we are in an EdenFS checkout
    if [ -x "$(command -v eden)" ] && eden info >/dev/null 2>&1; then
        CP_FLAGS="-X"
    else
        CP_FLAGS=""
    fi

[sebastiancarlos]

Looks like this was done already: blakef@e70076a