bad interpreter: Operation not permitted on Lion 10.7.3

Me too! Been using a backup script that (I created using TextEdit) rsyncs to my NAS for about a year but it suddenly stopped worked a few weeks back. All I did to 'fix' was open the script in TextWrangler and saved it!?!? The script is now working again.

Thanks for the suggestions.

All these answers are useless spam! The only thing that says what's really going on and a solution that works is described here:

http://stackoverflow.com/questions/9952612/mac-os-usr-bin-env-bad-interpreter-op eration-not-permitted

Short: run this command and you should be fine.

xattr -d com.apple.quarantine <YOUR FILE HERE>

Moderators should delete alle the spam in here.

What you have provided was already pointed up by Frank Caggiano, and is a solution for 1 file (and arguably, a group of files) but you offer nothing in regard to preventing it in the first place, and you managed to insult everyone who HAS offered a solution to the problem occuring in the firt place.

Pluses and minuses are nearly equal. Maybe YOU could post without the attitude?

anthon9969 wrote:

To fix it i had to go to the TextEdit file that I saved as hello.sh and right click, select Get Info and go to select Open with drop down menu and choose and select Open with: TextEdit.

This fixed it for me.

I could use some help with a similar error. I'm not a programmer. I installed VirtualBox, and decided to go with Parallels. When I double click VirtualBox_Uninstall.tool, I get:

Last login: Thu Oct 11 07:53:04 on console

/Volumes/VirtualBox/VirtualBox_Uninstall.tool ; exit;

davids-iMac:~ david seln$ /Volumes/VirtualBox/VirtualBox_Uninstall.tool ; exit;

-bash: /Volumes/VirtualBox/VirtualBox_Uninstall.tool: /bin/sh: bad interpreter: Operation not permitted

logout

[Process completed]

Any ideas?

From our recent conversation, i know you have resolved the VirtualBox removal issue. Should you have a future bad interpreter: Operation not permitted issue, the following link has a solution that works for that error. It is similar to Linc's Find syntax earlier in this post.

TextEdit is not a true code editor, and in your case, may add undesireable attributes to your code.

Pico, vi, vim, Sublime Text 2, Chocolate, Textmate, Xcode editor, and others treat code as code, hence your experience with Pico.

VikingOSX wrote:

TextEdit is not a true code editor, and in your case, may add undesireable attributes to your code.

Pico, vi, vim, Sublime Text 2, Chocolate, Textmate, Xcode editor, and others treat code as code, hence your experience with Pico.

actually if you know how to use it.. it is a true text editor and will not add anything weird.

The errors here have nothing to do with the file itself, but Gatekeeper.

🙂 😀 this is the one that got me past my permission denied. this was the one. the article is genius giving options of de-quaratining a file, folder or system. superb job! onwards and upwards... 😝

I had this problem too, appearing on 10.8.3

It appeared after I had some FS damage, I think due to VirtualBox creating a VDI badly. I repaired the FS and the permissions. After that I saw this error when trying to run scripts that I work on inside a HFS+ case sensitive disk image. The same problem was happening for very simple scripts I created after the problem started.

None of the suggestions I have read in this thread resolved the issue. What eventually resolved it for me was to create a new disk image, copy the files across, and then, for each script, to do:

cat script > new_script

rm script

chmod +x new_script

mv new_script script

Hours were wasted figuring out this problem.

When running the command (xattr -d com.apple.quarantine <YOUR FILE HERE>) through an application environment I'm having error:

xattr: [Errno 1] Operation not permitted: <YOUR FILE HERE>

How I can fix this? Which command I should use to overcome? I'm on Yosemite.

Where is "."? Have you installed programs into /usr or /bin somewhere? If so, they are gone. /usr/local would be a better place for them.

What do you get from "ls -@Oel" on one of the problem scripts?

Yes, but the current working directory is highly context-dependent. Are you able to execute a script that just calls "env" or "echo"?

Maybe remove that space before /bin/bash and see if that helps.