The return value from xcrun / the underlying command isn't returned to the caller for these as written. Either -e option (errexit) to /bin/sh and/or using exec to run the subcommand should resolve; not sure which is best practice.

@cmaloney Are you sure about that? From my testing:

$ iOS/Resources/bin/arm64-apple-ios-simulator-clang -c hello.c -o hello
$ echo $?
0
$ iOS/Resources/bin/arm64-apple-ios-simulator-clang
clang: error: no input files
$ echo $?
1 

Or am I missing something here?

set -e or equivalent would only be needed if there were another command following the xcrun, no? Otherwise, the stub script will exit with the status of the last executed command, that is, the command executed by xcrun.

Agreed it works in common / simple form today, have run into issues with wrappers as they get more complex.

Using exec would reduce resources a bit (less stacks/fork) and make it so there isn't any exit code forwarding or other stdin/stdout/stderr piping needed (the exec process replaces the shell rather than a fork+exec). -e would makes sure both in the simple case (only one command) or if more get used (ex. run this command to calculate path, then run with that path) it keeps working. Generally in shell scripts I like set -euo pipefail so that many common errors produce an error exit in the shell script. If those errors can't/don't occur (ex. this case doesn't use piping) then it doesn't hurt to have the checks, just means in general the shell scripts have a more safe environment. Agreed it works here as is / simple enough but first script commits to me tend to be starting points for growth as environments change/evolve and "just this little tweak" will fix.