Bash shell script not able to run?

I am attempting to create a simple bash script on MacOS (Mojave 10.14.5) and the script will not execute (permissions are set to execute!). The error returned is “/bin/bash: bad interpreter: Operation not permitted” .
From what I can determine via web searching there is a file attribute com.apple.quarantine that has a value of 21 and this is preventing the script from being executed.
My other, very much older, scripts in this folder do not have this attribute set at all. So I am assuming MacOS is doing this to prevent malicious actors from adding and executing scripts without our knowledge.

My web searches have provided various options for correcting this issue for individual scripts but I can find not decent description from Apple (having checked at the Developers site) as to how user should approach this problem. I also have not seen anything that says we should not write shell scripts.

Has anyone on this forum run into this problem and/or found any decent documentation on this topic?
Thanks,
Chip
The following two lines produce the results described. The script is located in ~/Scripts and this directory is on my path.
#!/bin/bash
echo “Test”

Have you tried something like this yet?

xattr -d com.apple.quarantine ~/Scripts/your_script.sh

I have seen this and some other similar options but wanted to understand Apple’s intent to select a “best” approach. I can simply add this step after adding execute permissions. Just don’t want to do things like this without understanding Apple’s intent if possible. The lack of obvious documentation makes me suspect I will simply need to modify the attributes.

As I understand it the quarantine functionality in MacOS identifies things from 'suspicious sources (like the Internet) and flags them for approval before you can execute them.

Similarly if there are attributed files on say a thumb drive, then the quarantine might kick in if any of the other files in the same location have the attribute set. I’ve not seen this myself, but have seen a handful of discussions over the years where tis seems to have been the case.

In general, if you are creating scripts from scratch on your local drive, and they aren’t matching any suspicious malware sorts of patterns that the quarantiner is looking for, then you shouldn’t have to unset anything.

HT201940 loos to be he official Apple support document on file quarantining, but it doesn’t discuss it down to the terminal execution level.

I had not seen the quarantine file, thanks for that. I can understand this would happen for files being downloaded onto my Mac but I created this file using BBEdit.

Oh well - will use xattr and move on.

Thanks for responding!

the xattr command you provided works fine, one time. When I run the shell script it will execute once then the quarantine attribute is again set. Will dig into it some more to find out how to turn off the setting of the flag

Not necessarily recommending it, but this article suggests a way to disable quarantining if it is proving painful.

Has terminal got full disk access?

Sorry I dropped off this topic. Here is a quick status.

To answer the question about disk access, I never granted Terminal full disk access. Then again it never asked for it.

I ended up taking advantage of AppleCare and called the help desk. They support team really didn’t even know how to answer so they kicked this over to the Engineering team. They eventually got back to the fellow supporting me and told him that it was an issue with gatekeeper preventing a 3’rd party app, BBEdit (my copy is downloaded not from the App Store) from creating executable content.

So I can fix this every time I edit the script. I do eventually intend to contact the BBEdit folks, I a, sure I am not the first person to do this, will eventually get around to it.

According to the current BBEdit release notes, this is a result of the app being sandboxed even if you buy directly from them. To fix this, go to Preferences->Application and enable the sandbox access setting. This will permanently fix this issue.

2 Likes