Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

/bin/sh: bad interpreter: Operation not permitted

1,065 views
Skip to first unread message

Wes Groleau

unread,
Feb 21, 2012, 6:01:27 PM2/21/12
to
iMac:~ wgroleau$ time UniGen-update
-bash: /Users/wgroleau/bin/UniGen-update: /bin/sh: bad interpreter:
Operation not permitted

Just a brief revisiting of this. It is indeed SORT OF what someone
suggested, a non-standard (from the Unix point-of-view) line break.
It happens every time I edit the script, and it is always fixed by
perl -p -i -e 's:\r:\n:g;' bin/UniGen-update

But the weird thing is that if I examine the file (before fixing) with
either vim or 'od -xc' I _cannot_ find a single instance or \r or its
hex value!

--
Wes Groleau

“A man with an experience is never
at the mercy of a man with an argument.”
— Ron Allen

Jolly Roger

unread,
Feb 21, 2012, 6:15:21 PM2/21/12
to
In article <ji17o8$ket$1...@dont-email.me>,
Wes Groleau <Grolea...@FreeShell.org> wrote:

> iMac:~ wgroleau$ time UniGen-update
> -bash: /Users/wgroleau/bin/UniGen-update: /bin/sh: bad interpreter:
> Operation not permitted
>
> Just a brief revisiting of this. It is indeed SORT OF what someone
> suggested, a non-standard (from the Unix point-of-view) line break.
> It happens every time I edit the script, and it is always fixed by
> perl -p -i -e 's:\r:\n:g;' bin/UniGen-update
>
> But the weird thing is that if I examine the file (before fixing) with
> either vim or 'od -xc' I _cannot_ find a single instance or \r or its
> hex value!

What are you editing it with?

--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR

Richard Kettlewell

unread,
Feb 22, 2012, 5:13:59 AM2/22/12
to
Wes Groleau <Grolea...@FreeShell.org> writes:
> iMac:~ wgroleau$ time UniGen-update
> -bash: /Users/wgroleau/bin/UniGen-update: /bin/sh: bad interpreter:
> Operation not permitted
>
> Just a brief revisiting of this. It is indeed SORT OF what someone
> suggested, a non-standard (from the Unix point-of-view) line break.
> It happens every time I edit the script, and it is always fixed by
> perl -p -i -e 's:\r:\n:g;' bin/UniGen-update
>
> But the weird thing is that if I examine the file (before fixing) with
> either vim or 'od -xc' I _cannot_ find a single instance or \r or its
> hex value!

Try
perl -p -i -e '' bin/UniGen-update
instead next time. I suspect that the change is not in the contents of
the file (if there aren't any CRs then your perl one-liner won't remove
them) but is down to the fact of rewriting it.

What are you using to edit the file?

--
http://www.greenend.org.uk/rjk/

Barry Margolin

unread,
Feb 22, 2012, 10:06:40 AM2/22/12
to
In article <87k43f1...@araminta.anjou.terraraq.org.uk>,
Yeah, sounds like it may be an issue of OS X metadata.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Wes Groleau

unread,
Feb 22, 2012, 9:27:35 PM2/22/12
to
On 02-22-2012 10:06, Barry Margolin wrote:
> Richard Kettlewell<r...@greenend.org.uk> wrote:
>> Wes Groleau<Grolea...@FreeShell.org> writes:
>>> iMac:~ wgroleau$ time UniGen-update
>>> -bash: /Users/wgroleau/bin/UniGen-update: /bin/sh: bad interpreter:
>>> Operation not permitted
>>>
>>> Just a brief revisiting of this. It is indeed SORT OF what someone
>>> suggested, a non-standard (from the Unix point-of-view) line break.
>>> It happens every time I edit the script, and it is always fixed by
>>> perl -p -i -e 's:\r:\n:g;' bin/UniGen-update
>>>
>>> But the weird thing is that if I examine the file (before fixing) with
>>> either vim or 'od -xc' I _cannot_ find a single instance or \r or its
>>> hex value!
>>
>> Try
>> perl -p -i -e '' bin/UniGen-update
>> instead next time. I suspect that the change is not in the contents of
>> the file (if there aren't any CRs then your perl one-liner won't remove
>> them) but is down to the fact of rewriting it.
>>
>> What are you using to edit the file?

TextEdit

> Yeah, sounds like it may be an issue of OS X metadata.

It does, and yet, for the shell and/or perl to choke on the metadata is
kind of hard to believe.

--
Wes Groleau

“Missing a train is only painful if you run after it!”
— Nassim Nicholas Taleb

Jolly Roger

unread,
Feb 23, 2012, 1:15:53 AM2/23/12
to
In article <ji486n$hm7$2...@dont-email.me>,
I wouldn't advise using a simple rich text editor like TextEdit to edit
plain text files - especially command-line stuff. While TextEdit can be
made to edit in plain text mode, it's been known to misbehave and cause
problems with plain text files. Personally, I use TextWrangler. It's
made for the task and excels at it.

Paul Sture

unread,
Feb 23, 2012, 5:10:36 AM2/23/12
to
On Thu, 23 Feb 2012 00:15:53 -0600, Jolly Roger wrote:

> In article <ji486n$hm7$2...@dont-email.me>,
> Wes Groleau <Grolea...@FreeShell.org> wrote:
>

>> >>
>> >> What are you using to edit the file?
>>
>> TextEdit
>>
>> > Yeah, sounds like it may be an issue of OS X metadata.
>>
>> It does, and yet, for the shell and/or perl to choke on the metadata is
>> kind of hard to believe.
>
> I wouldn't advise using a simple rich text editor like TextEdit to edit
> plain text files - especially command-line stuff. While TextEdit can be
> made to edit in plain text mode, it's been known to misbehave and cause
> problems with plain text files. Personally, I use TextWrangler. It's
> made for the task and excels at it.

Plus TextWrangler gives you the status bar telling you the encoding and
line terminators in use. That has explained a few WTF? situations for me.



--
Paul Sture
Message has been deleted

Richard Kettlewell

unread,
Feb 23, 2012, 5:51:39 AM2/23/12
to
We've done this. The shell is not choking on anything; it doesn't get
to run in the first place. The EPERM is from execve().

--
http://www.greenend.org.uk/rjk/

Jolly Roger

unread,
Feb 23, 2012, 8:15:15 AM2/23/12
to
In article <87sji1n...@araminta.anjou.terraraq.org.uk>,
Yes, and the reason this is coming up again is your terse "EPERM is from
execve()" offering hasn't actually helped solve the issue. If you can't
help actually solve the issue, I don't see much use in repeating
yourself.

Richard Kettlewell

unread,
Feb 23, 2012, 8:38:22 AM2/23/12
to
Jolly Roger <jolly...@pobox.com> writes:
> Yes, and the reason this is coming up again is your terse "EPERM is
> from execve()" offering hasn't actually helped solve the issue. If you
> can't help actually solve the issue, I don't see much use in repeating
> yourself.

It wasn't terse the first time round, nor particularly so the second or
third time. I'd suggest you revisit those, but I already suggested that
once without any apparent effect. So I'll suggest instead that you look
up the relevant code and documentation yourself. It's not particularly
hard to find.

--
http://www.greenend.org.uk/rjk/

Jolly Roger

unread,
Feb 23, 2012, 8:49:17 AM2/23/12
to
In article <87mx89m...@araminta.anjou.terraraq.org.uk>,
Richard Kettlewell <r...@greenend.org.uk> wrote:

> Jolly Roger <jolly...@pobox.com> writes:
> > Yes, and the reason this is coming up again is your terse "EPERM is
> > from execve()" offering hasn't actually helped solve the issue. If you
> > can't help actually solve the issue, I don't see much use in repeating
> > yourself.
>
> It wasn't terse the first time round, nor particularly so the second or
> third time.

Yet even with that wealth of "helpful" information, the OP was somehow
unable to solve the issue. Odd.

> I'd suggest you revisit those, but I already suggested that
> once without any apparent effect. So I'll suggest instead that you look
> up the relevant code and documentation yourself. It's not particularly
> hard to find.

Lucky for me, I'm not the one with the problem, so I don't have to parse
your "helpful" advice and resort to looking up error messages because
you haven't really helped. Seems like you've done a stellar job
"helping" them. I guess they should thank you profusely.

Barry Margolin

unread,
Feb 23, 2012, 10:34:53 AM2/23/12
to
In article <87sji1n...@araminta.anjou.terraraq.org.uk>,
So? The point still remains: nothing involved in this process should
care about metadata, so there seems to be a bug if it chokes because of
it.

Richard Kettlewell

unread,
Feb 23, 2012, 11:21:28 AM2/23/12
to
The kernel probably cares about quarantine attributes.

I did ask for 'xattr -l' output a while back, but I don't think an
answer ever appeared.

--
http://www.greenend.org.uk/rjk/

Richard Kettlewell

unread,
Feb 23, 2012, 2:24:20 PM2/23/12
to
Wes Groleau <Grolea...@FreeShell.org> writes:
> Barry Margolin wrote:
>> Richard Kettlewell<r...@greenend.org.uk> wrote:

>>> Try
>>> perl -p -i -e '' bin/UniGen-update
>>> instead next time. I suspect that the change is not in the contents of
>>> the file (if there aren't any CRs then your perl one-liner won't remove
>>> them) but is down to the fact of rewriting it.
>>>
>>> What are you using to edit the file?
>
> TextEdit

...and there we go:

chymax$ cat foo
#! /bin/bash
echo running
chymax$ ls -l foo
-rwxr-xr-x@ 1 richard richard 26 23 Feb 19:18 foo
chymax$ xattr -l foo
com.apple.TextEncoding: utf-8;134217984
com.apple.quarantine: 0006;4f4690ff;TextEdit;
chymax$ ./foo
-bash: ./foo: /bin/bash: bad interpreter: Operation not permitted
chymax$ xattr -d com.apple.quarantine foo
chymax$ ./foo
running

TextEdit sets a quarantine attribute on the script. Remove the
attribute (or rewrite the file with some other tool) and it should run
fine.

--
http://www.greenend.org.uk/rjk/

Richard Kettlewell

unread,
Feb 23, 2012, 2:37:43 PM2/23/12
to
Jolly Roger <jolly...@pobox.com> writes:
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Jolly Roger <jolly...@pobox.com> writes:

>>> Yes, and the reason this is coming up again is your terse "EPERM is
>>> from execve()" offering hasn't actually helped solve the issue. If you
>>> can't help actually solve the issue, I don't see much use in repeating
>>> yourself.
>>
>> It wasn't terse the first time round, nor particularly so the second or
>> third time.
>
> Yet even with that wealth of "helpful" information, the OP was somehow
> unable to solve the issue. Odd.

I'd point out that at least two of the questions in my original posting,
had they been answered, would have rapidly led to the answer.

I'm sure you'll find a way to blame me for that, though.

--
http://www.greenend.org.uk/rjk/

Barry Margolin

unread,
Feb 23, 2012, 5:20:13 PM2/23/12
to
In article <87sji19...@araminta.anjou.terraraq.org.uk>,
I wonder why TextEdit quarantines its files. I thought that was for
files downloaded from the Internet, since they're potentially dangerous.

Wes Groleau

unread,
Feb 23, 2012, 11:44:28 PM2/23/12
to
On 02-23-2012 05:51, Richard Kettlewell wrote:
> We've done this. The shell is not choking on anything; it doesn't get
> to run in the first place. The EPERM is from execve().

REPEAT:

perl -p -i -e 's:\r:\n:g;' <scriptname>

makes the error go away, even though no \r can be found in the file.


--
Wes Groleau

Words of the Wild Wes
http://Ideas.Lang-Learn.us/WWW

Wes Groleau

unread,
Feb 23, 2012, 11:47:49 PM2/23/12
to
On 02-23-2012 17:20, Barry Margolin wrote:
> I wonder why TextEdit quarantines its files. I thought that was for
> files downloaded from the Internet, since they're potentially dangerous.

And perl clears the quarantine, and a quarantined file is reported as
"bad interpreter"

Fascinating.

--
Wes Groleau

“Would the prodigal have gone home if
the elder brother was running the farm?”
— James Jordan

Barry Margolin

unread,
Feb 24, 2012, 12:49:24 AM2/24/12
to
In article <ji74pl$gp4$4...@dont-email.me>,
Wes Groleau <Grolea...@FreeShell.org> wrote:

> On 02-23-2012 17:20, Barry Margolin wrote:
> > I wonder why TextEdit quarantines its files. I thought that was for
> > files downloaded from the Internet, since they're potentially dangerous.
>
> And perl clears the quarantine, and a quarantined file is reported as
> "bad interpreter"
>
> Fascinating.

Perl doesn't actually clear the quarantine, it creates a new file that
isn't quarantined.

As has already been pointed out, "Bad interpreter" is the message the
shell displays if it gets any error trying to execute a script. The OS
doesn't let you execute quarantined scripts (it can't do the equivalent
of popping up the "This file was downloaded from the Internet, are you
sure you want to run it?" dialog).
0 new messages