Take the 2-minute tour ×

I'm trying to run this script on Mac OS 10.7 (Lion) and I'm getting the error:

$ bbcolors
-bash: /usr/local/bin/bbcolors: /usr/bin/env: bad interpreter: Operation not permitted

I've successfully run this script on other Macs of mine. It's just this script downloaded and unmodified from Daring Fireball.

I found this person with a very similar problem but the accepted answer was that the filesystem had a 'noexe' option on mount. I'm pretty sure that's not the case for me because I've just got it in /usr/local/bin/ and other stuff in there works fine (it also doesn't run from other places or as other users including root).

$ which bbcolors
$ ls -l /usr/local/bin/bbcolors 
-rwxr-xr-x@ 1 nick  staff  9751 Mar 30 19:09 /usr/local/bin/bbcolors

It's a Perl script not a compiled binary, not that that should matter. Here's some extra info for what it's worth:

$ cat /usr/local/bin/bbcolors |head -n 1
#!/usr/bin/env perl
$ which perl
$ env | grep PATH
share|improve this question
You've covered most of the normal bases for what might be going wrong; well done. What happens when you run perl -v? What appears after the initial comment lines in the Perl script (bbcolors)? Also, the @ after the permissions means there is some auxilliary attribute information for the file; have you investigated that that is (perhaps with ls -@)? –  Jonathan Leffler Mar 31 '12 at 2:58
perl -v gives the standard info. You can see the whole script from the link above but I think you're on to something with the @ symbol. According to this it indicates extended permissions in Mac OS X. When I run ls -al@ /usr/local/bin/bbcolors I get this message: -rwxr-xr-x@ 1 nick staff 9751 Mar 30 19:42 /usr/local/bin/bbcolors com.apple.quarantine 74 So it seems OS X has quarantined it for some reason. –  nickv2002 Mar 31 '12 at 3:08
I solved the problem with xattr -r com.apple.quarantine /file/path I will answer my own question but I don't have enough rep to do it for a few hours. –  nickv2002 Mar 31 '12 at 3:19
xattr -d com.apple.quarantine /usr/local/bin/bbcolors? (-r means 'recursive'; -d means 'delete'.) I keep forgetting what that command is called. –  Jonathan Leffler Mar 31 '12 at 3:23
add comment

4 Answers

up vote 32 down vote accepted

Did you happen to open/save the file in TextEdit?

That can introduce filesystem metadata (quarantine attribute) leading to the symptom you describe.


xattr -l /usr/local/bin/bbcolors


xattr -d com.apple.quarantine /usr/local/bin/bbcolors

if you see the quarantine attribute.

share|improve this answer
Yeah, I couldn't answer my own question, but you've got the right info out of my my comments above. FWIW: it's also worth doing a ls -al@ on the file to see the com.apple.quarantine. –  nickv2002 Mar 31 '12 at 3:27
Ha. I found that solution without reading your comments. That'll teach me to refresh more often. –  pilcrow Mar 31 '12 at 3:29
For reference, if you realize you have a whole directory tree with the com.apple.quarantine attribute, run xattr -dr com.apple.quarantine . from inside the directory to clean all files within it. I got a mass-quarantined directory like that by unzipping a zip file I had copied over a local network. –  Rory O'Kane May 7 '12 at 20:21
The com.apple.quarantine might also be set on the Disk Image, causing it to be mounted with quarantine. –  eile Mar 14 '13 at 15:14
For sparse images, I did not find the com.apple.quarantine attribute on the sparsebundle itself but it was hiding on a file inside the bundle. The -r flag was necessary to clear the attribute. –  jrc Oct 6 '13 at 12:16
show 2 more comments

pilcrow's answer is correct, however I draw your attention to the fact that if you are working with a disk image, the problem can be very confusing, as the com.apple.quarantine attribute seems to be inherited from the disk image file to the files inside (thanks to febeling at Apple dev forums for noticing that!).

To solve the problem, you have to remove the quarantine attribute from the disk image:

xattr -d com.apple.quarantine /path/to/disk/image

and then eject and remount the disk image. Then your files will be clean again.

share|improve this answer
+1 Thanks! You saved my day. –  ilmiacs Mar 15 '13 at 11:29
+1 Thanks! Saved my day too! –  Benson Wong May 27 '13 at 22:40
add comment

I had resolved this issue.Open the command file with TextEdit then save it.

More Info:Resolved Operation not permitted

share|improve this answer
add comment

Does /usr/bin/env exist? Can you run it? Run by itself it should dump your environment variables to stdout.

You can safely replace:

#!/usr/bin/env perl

With the full path to your perl binary of choice, e.g:

share|improve this answer
add comment

Your Answer


