3

I am using macOS with SIP enabled. And I am figuring out why the scripts run so slowly with the SIP after a modification or creation.

And I found if I modify a script by editors like vim or nano, and run it by ./script.bash, it will take about 1 second to finish the script for the first time after each modification.

For example. If the script.bash is:

#!/bin/bash echo 1

And I change it to below by vim. It takes me about ten times longer time to run it.

#!/bin/bash echo 1 echo 2 
bash-3.2$ time ./script.bash # First time after modification by vim 1 2 real 0m0.884s user 0m0.001s sys 0m0.002s 
bash-3.2$ time ./script.bash # Second time after modification by vim 1 2 real 0m0.003s user 0m0.001s sys 0m0.002s

While if I currently append the file by some command's output redirection like echo "echo 3" >> script.bash and still call the script by ./script.bash, the delay is gone.

bash-3.2$ echo "echo 3" >> script.bash bash-3.2$ time ./script.bash # First time after modification by echo 1 2 3 real 0m0.004s user 0m0.001s sys 0m0.002s bash-3.2$ time ./script.bash # Second time after modification by echo 1 2 3 real 0m0.002s user 0m0.001s sys 0m0.001s

So what's the difference between the two ways of writing a file? And why the delay happens only with SIP enabled?

Improve this question
3
  • You probably need to expand on what "SIP" is in this context. Commented Aug 10, 2020 at 16:59
  • I can reproduce this on my mac although the delays are significantly lower. I'm not sure SIP is related though as it shouldn't have any affect on the directory I'm working out of. Commented Aug 10, 2020 at 17:03
  • @jesse_b I am sure the delay is caused by the SIP by switching it multiple times. I don't know the internal details but I suspect it is because of the exec(), because bash ./script.bash executes the script smoothly. But it is really annoying when I am practising scripting, almost every modification cause a more second delay to finish. And compared to reason the why it delays, I am more curious at why the second way makes no delays. Because I think the only choice to solve the problem is disable SIP,lol. Commented Aug 10, 2020 at 17:15

1 Answer 1

Reset to default
3

I found this article which I believe explains your issue.

Apple has introduced notarization, setting aside the inconvenience this brings to us developers, it also results in a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server. This check for me takes close to a second.

This is not just for files downloaded from the internet, nor is it only when you launch them via Finder, this is everything. So even if you write a one line shell script and run it in a terminal, you will get a delay!

As for the notarization check, the result is cached, so second invocation should be fast, but if you are a developer, you may update your scripts and binaries regularly, which trigger new checks (it appears caching is based on inode, so an update-in-place save may avoid triggering a new check), or you may have workflows that involve dynamically creating and executing scripts, which performance now hinges upon the responsiveness of Apple’s servers.

It seems that modifying the file through an editor modifies the inode causing it to be checked again but appending it with a redirect does not.

Improve this answer
1
  • that was also my first thought when reading the headline (altough i didn't know what SIP is). almost all text editors (even sed -i) work with tmp files internally and replace the origin instead of changing it Commented Aug 11, 2020 at 11:34

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.