Shell scripts do not run anymore; problems after 10.7.3?

Question

Shell scripts do not run anymore; problems after 10.7.3?

Hello all,

latley all my shell scripts broke and they do not run anymore. I suspect 10.7.3 to broke all the scripts. My scripts used to work fine and I had no issues. I guess it started after updateing to 10.7.3 and now I got a error as following:

-bash: ./CamSendEmail.sh: /bin/bash: bad interpreter: Operation not permitted

This is usually as the first line in my script is and ever was #!/bin/bash. If I do just remove the line, I am getting an error as following:

-bash: ./CamSendEmail.sh: Operation not permitted

Please note, that the scripts name is "CamSendEmail.sh" and that this is just an example. All my scripts are affected. At this point I need to say again, that the scripts work basicly fine till a short time ago.

Of cause, the user who runs the scripts has the permission to run the script. It is a standard user and it ever was. I did not touch the scripts nor their permissions. The only change I am aware of is updating to 10.7.3.

I did a test and cut'n'pasted the entire content of a not running script into a blank new file. The new file did work! The only differences between those 2 files are now some file system permission, I do actually not know yet:

-rwxr--r--+ 1 james staff 265 Feb 13 19:50 CamSendEmail.sh
-rwxr--r--@ 1 james staff 265 Feb 13 19:40 CamSendEmail.sh.orig

Note, that *orig does not work, while *sh does. I could not find an information about the meaning of a + and the @ in the output of ls -al. But whatever it is, I wonder how this can be influenced by 10.7.3 ...(?) Can anyone shade a little light on that?

I will keep on searching for information about + an @, but since this is somehow urgent to me, I decided to first start this posting ...

Thx for your help on that!

Posted on Feb 13, 2012 11:00 AM

Reply

Answer 1

Feb 13, 2012 11:36 AM in response to Thomas Halenbeck

I did some research and learned the the + and the @ are indicating extented attributes which can be managed using the xattr command. I played a little bit with it, and found out that my scripts had the following extended attribute for some reason

com.apple.quarantine

I deleted it using xattr -d com.apple.quarantine script.sh and the script worked again. This is one point.

What still drives me nuts, is the fact that this attribute was set without any interaction of me. Does anyone know if Apple has build in some new security stuff with 10.7.3? Or is this just accidential and some other action, which I am not aware of, has changed or added the extended attributes?

I realy would like to have that clarified. My scripts are part of an automated process and it took some days till I noted that this process does not work anymore, which resulted in data loss. I was happy that those days data was not very important. Now I am afraid that this may happen again any time :-(

Thx again!

Reply

Answer 2

Feb 14, 2012 3:09 AM in response to Thomas Halenbeck

same happened to me after updating to Lion. instead of com.apple.quarantine I had com.apple.TextEncoding and every time I tried to open the file in text editor it gave me the message that this file was downloaded from the internet.... bla bla bla

I used the solution you recommended and the problem is fixed.

Reply

Answer 3

Feb 14, 2012 6:05 AM in response to Alexander Costa

Yep,

I noticed the com.apple.TextEncoding as well. So it seems that at least we both stepped into the same trap 😢

Just like you, I ignored the TextEncoding attribute and it did not harm the script execution. I am still pretty mad, that Lion introduce so much trouble. 10.7.3 broke my FTP server as well and really hope that I do not need to fix all kinds of stuff every time Lion gets updated 😠

Reply

Answer 4

markGD

Level 1

0 points

Apr 6, 2012 10:06 AM in response to Thomas Halenbeck

Thanks Thomas, saved me hours of effort. Using OS X 10.7.3 - had the same problem with a new script written with a plain text editor and mv'd from Documents to usr/bin. Wherever it was located, the script would run in a second shell using

$sh myscript

but it would not run using just

$myscript

which gave Operation not permitted, until I applied your solution.

So I guess the quarantine is to force users to run a second shell?

Reply

Answer 5

doh1231

Level 2

210 points

Apr 10, 2012 5:15 AM in response to Thomas Halenbeck

I have a feeling this is a bug in the changes they made for Gatekeeper in 10.7.3...

If I open a new TextEdit Window and write the following script...

#!/bin/bash

echo TEST

then save it, go to Terminal and chmod 755 on it.... then go back in Finder and double click, i get the...

"XXXX" is a Unix application downloaded from the Internet, Are you sure you want to open it? TextEdit downloaded this file today at 7:30 AM."

message... which is stupid. I just wrote the script, it wasn't downloaded.

If I press to Open on that message, it also clears the quarantine and then the script starts running fine from command line without that error message.

Reply

Answer 6

markGD

Level 1

0 points

Apr 12, 2012 1:30 AM in response to doh1231

Looks like a threat response to me:

If I create a shell script test.sh using Xcode (empty project, Shell Script file template) then the quarantine extended attribute is not set, and it will execute directly from the terminal as /path/test.sh after chmod +x /path/test.sh .

If I create the identical script test1.sh using TextEdit.app then it will run in its own shell after chmod +x (sh /path/test1.sh) but not otherwise (Operation not permitted), and xattr /path/test1.sh shows com.apple.quarantine.

So whether this attribute is set seems to depend on the editor used to create the script.

Reply