/bin/sh: bad interpreter: Operation not permitted

Showing 1-20 of 20 messages
/bin/sh: bad interpreter: Operation not permitted Wes Groleau 2/21/12 3:01 PM
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

Re: /bin/sh: bad interpreter: Operation not permitted Jolly Roger 2/21/12 3:15 PM
In article <ji17o8$ket$1...@dont-email.me>,
 Wes Groleau <Groleau+news@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
Re: /bin/sh: bad interpreter: Operation not permitted Richard Kettlewell 2/22/12 2:13 AM
Wes Groleau <Groleau+news@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/
Re: /bin/sh: bad interpreter: Operation not permitted Barry Margolin 2/22/12 7:06 AM
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 ***
Re: /bin/sh: bad interpreter: Operation not permitted Wes Groleau 2/22/12 6:27 PM
On 02-22-2012 10:06, Barry Margolin wrote:
>   Richard Kettlewell<r...@greenend.org.uk>  wrote:
>> Wes Groleau<Groleau+news@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

Re: /bin/sh: bad interpreter: Operation not permitted Jolly Roger 2/22/12 10:15 PM
In article <ji486n$hm7$2...@dont-email.me>,
 Wes Groleau <Groleau+news@FreeShell.org> wrote:

> On 02-22-2012 10:06, Barry Margolin wrote:
> >   Richard Kettlewell<r...@greenend.org.uk>  wrote:
> >> Wes Groleau<Groleau+news@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.

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.
Re: /bin/sh: bad interpreter: Operation not permitted Paul Sture 2/23/12 2:10 AM
On Thu, 23 Feb 2012 00:15:53 -0600, Jolly Roger wrote:

> In article <ji486n$hm7$2...@dont-email.me>,
>  Wes Groleau <Groleau+news@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
unk...@googlegroups.com 2/23/12 2:36 AM <This message has been deleted.>
Re: /bin/sh: bad interpreter: Operation not permitted Richard Kettlewell 2/23/12 2:51 AM
Wes Groleau <Groleau+news@FreeShell.org> writes:
> On 02-22-2012 10:06, Barry Margolin wrote:
>> Richard Kettlewell<r...@greenend.org.uk>  wrote:
>>> Wes Groleau<Groleau+news@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.

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/
Re: /bin/sh: bad interpreter: Operation not permitted Jolly Roger 2/23/12 5:15 AM
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.
Re: /bin/sh: bad interpreter: Operation not permitted Richard Kettlewell 2/23/12 5:38 AM
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/
Re: /bin/sh: bad interpreter: Operation not permitted Jolly Roger 2/23/12 5:49 AM
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.
Re: /bin/sh: bad interpreter: Operation not permitted Barry Margolin 2/23/12 7:34 AM
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.
Re: /bin/sh: bad interpreter: Operation not permitted Richard Kettlewell 2/23/12 8:21 AM
Barry Margolin <bar...@alum.mit.edu> writes:
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Wes Groleau <Groleau+news@FreeShell.org> writes:
>>> On 02-22-2012 10:06, Barry Margolin wrote:

>>>> 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.
>>
>> 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().
>
> 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.

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/
Re: /bin/sh: bad interpreter: Operation not permitted Richard Kettlewell 2/23/12 11:24 AM
Wes Groleau <Groleau+news@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/
Re: /bin/sh: bad interpreter: Operation not permitted Richard Kettlewell 2/23/12 11:37 AM
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/
Re: /bin/sh: bad interpreter: Operation not permitted Barry Margolin 2/23/12 2:20 PM
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.
Re: /bin/sh: bad interpreter: Operation not permitted Wes Groleau 2/23/12 8:44 PM
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

Re: /bin/sh: bad interpreter: Operation not permitted Wes Groleau 2/23/12 8:47 PM
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

Re: /bin/sh: bad interpreter: Operation not permitted Barry Margolin 2/23/12 9:49 PM
In article <ji74pl$gp4$4...@dont-email.me>,
 Wes Groleau <Groleau+news@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).