/bin/sh: bad interpreter: Operation not permitted

[Wes Groleau]

I made some "enhancements" to a script and now it won't run.

iMac:~ wgroleau$ bin/RandiGen
-bash: bin/RandiGen: /bin/sh: bad interpreter: Operation not permitted
iMac:~ wgroleau$ od -xc bin/RandiGen | head
0000000 2123 622f 6e69 732f 0a68 630a 2064 562f
# ! / b i n / s h \n \n c d / V
0000020 6c6f 6d75 7365 492f 4448 7461 2f61 5447
o l u m e s / I H D a t a / G T
0000040 4353 442f 6f72 6270 786f 552f 2f47 6577
S C / D r o p b o x / U G / w e
0000060 7462 6572 7365 642f 7461 0a61 200a 2020
b t r e e s / d a t a \n \n
0000100 2020 2020 0a20 6765 6572 2070 3022 4020
\n e g r e p " 0 @
iMac:data wgroleau$ which sh
/bin/sh
iMac:data wgroleau$ /bin/sh
ps: No user named 'xww'
sh-3.2$ ls -lat /bin/sh
-r-xr-xr-x 1 root wheel 1371712 Oct 29 16:15 /bin/sh
sh-3.2$

I don't see any reason for the error. Do you?

I did not change the first line. I see that
invoking sh works (prompt changes), even though
it gives an odd message.

--
Wes Groleau

Those who make peaceful revolution impossible
will make violent revolution inevitable.
— John F. Kennedy

[Wes Groleau]

On 02-04-2012 20:40, Wes Groleau wrote:
> I made some "enhancements" to a script and now it won't run.
>

> .....

>
> I don't see any reason for the error. Do you?

Tried it a few times--definition of insanity--with the same result.

Did something else for a while, then tried it again and it worked.
--PROOF of insanity! :-)

[Jolly Roger]

In article <jgkmm0$7hp$1...@dont-email.me>,

Wes Groleau <Grolea...@FreeShell.org> wrote:

> I made some "enhancements" to a script and now it won't run.

(snip)

> iMac:data wgroleau$ /bin/sh
> ps: No user named 'xww'

(snip)

> I don't see any reason for the error. Do you?
>
> I did not change the first line. I see that
> invoking sh works (prompt changes), even though
> it gives an odd message.

The above error seems to indicate a shell startup script is
malfunctioning. The specific error happens when you pass "xww" as the -u
switch value to ps:

ps -uxww

ps: No user named 'xww'

Look in this user account's shell startup scripts (.profile,
.bash_profile, etc.) for "ps -uxww".

--
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

[Wes Groleau]

On 02-04-2012 22:18, Jolly Roger wrote:
> Look in this user account's shell startup scripts (.profile,
> .bash_profile, etc.) for "ps -uxww".

Yes, but " grep xww .??* " finds nothing in my home directory.
And it only does that when launching sh in Terminal.
The shell script that was refusing to run started working again for
no obvious reason, yet this error still occurs if I invoke sh

[Leonard Blaisdell]

In article <jgkotr$g7v$1...@dont-email.me>,

Wes Groleau <Grolea...@FreeShell.org> wrote:

> Tried it a few times--definition of insanity--with the same result.
>
> Did something else for a while, then tried it again and it worked.
> --PROOF of insanity! :-)

It is in real life but not on a computer. As a hobby, I used to compile
custom Linux 2.4 kernels on a Power Mac 9600. I'd compile and fail, and
compile and fail, and etc. I got a little further each time. Eventually
the damned thing would compile. I didn't change the parameters of the
enormously large config file after making the first entries. Must have
been a cache issue or forceful insistence on my part. Dunno.
So Einstein was wrong.

leo

[Richard Kettlewell]

Wes Groleau <Grolea...@FreeShell.org> writes:
> I made some "enhancements" to a script and now it won't run.
>
> iMac:~ wgroleau$ bin/RandiGen
> -bash: bin/RandiGen: /bin/sh: bad interpreter: Operation not permitted
> iMac:~ wgroleau$ od -xc bin/RandiGen | head
> 0000000 2123 622f 6e69 732f 0a68 630a 2064 562f
> # ! / b i n / s h \n \n c d / V
> 0000020 6c6f 6d75 7365 492f 4448 7461 2f61 5447
> o l u m e s / I H D a t a / G T
> 0000040 4353 442f 6f72 6270 786f 552f 2f47 6577
> S C / D r o p b o x / U G / w e
> 0000060 7462 6572 7365 642f 7461 0a61 200a 2020
> b t r e e s / d a t a \n \n
> 0000100 2020 2020 0a20 6765 6572 2070 3022 4020
> \n e g r e p " 0 @
> iMac:data wgroleau$ which sh
> /bin/sh
> iMac:data wgroleau$ /bin/sh
> ps: No user named 'xww'
> sh-3.2$ ls -lat /bin/sh
> -r-xr-xr-x 1 root wheel 1371712 Oct 29 16:15 /bin/sh
> sh-3.2$
>
> I don't see any reason for the error. Do you?

Somewhere, perhaps in a shell startup file, can be found the command
'ps -uxww'. This would probably have worked as expected in 10.4 (Tiger)
and earlier, and may still work on BSD systems, but Apple changed to the
SysV/SUS syntax for ps.

As for why you were getting EPERM ("Operation not permitted") from your
script, that is more of a puzzle.

EPERM is not a documented error code for execve(), making it hard to
infer what that reason is.

It's probably not permissions; that produces EACCES ("Permission
denied").

The message is formatted by Bash, and it's important to understand that
the reference to the interpreter rather than some aspect of RandiGen is
actually guesswork on Bash's part, and as such may be misleading.

Since you could run /bin/sh just fine, my guess would be that the script
itself could not be executed for some reason that Bash doesn't know
about. If it stops working again, it may be useful to:

ls -l bin/RandiGen
xattr -l bin/RandiGen

Could the filesystem containing RandiGen have been mounted with the
'noexec' flag (or anything else unusual)?

What tool(s) did you use to modify RandiGen?

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

[Bob Harris]

In article <jgkmm0$7hp$1...@dont-email.me>,

A "Wild Guess", but what is listed in /etc/shells:

cat /etc/shells
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

This file lists the valid shells. I suspect the "bad interpreter"
message might be coming from a corrupt /etc/shells file.

[Barry Margolin]

In article
<nospam.News.Bob-86...@news.eternal-september.org>,

Bob Harris <nospam....@remove.Smith-Harris.us> wrote:

> A "Wild Guess", but what is listed in /etc/shells:
>
> cat /etc/shells
> # List of acceptable shells for chpass(1).
> # Ftpd will not allow users to connect who are not using
> # one of these shells.
>
> /bin/bash
> /bin/csh
> /bin/ksh
> /bin/sh
> /bin/tcsh
> /bin/zsh
>
> This file lists the valid shells. I suspect the "bad interpreter"
> message might be coming from a corrupt /etc/shells file.

No. It's quite common to have #! lines that list other programs, such as
perl or python. Any scripting language can be used for this.

The only programs that care about /etc/shells are ftpd and chsh.

"Bad interpreter" means an error occurred when trying to run the program
named in the #! line. Usually it means the program doesn't exist. A
common cause of this is editing the file on a Windows machine and
copying it over, without converting the newlines to Unix style, so it
sees a CR in the program name.

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

[Richard Kettlewell]

Barry Margolin <bar...@alum.mit.edu> writes:
> "Bad interpreter" means an error occurred when trying to run the program
> named in the #! line.

That's usually true, but what is actually going on is that Bash assumes
that interpreter is wrong if it can't figure out any other reason for
execve() failing. I think a noexec filesystem is one case where it'll
guess wrong.

> Usually it means the program doesn't exist. A common cause of this is
> editing the file on a Windows machine and copying it over, without
> converting the newlines to Unix style, so it sees a CR in the program
> name.

We can see that neither of those are the case here though.

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

[Jolly Roger]

In article <barmar-549A6A....@news.eternal-september.org>,

Barry Margolin <bar...@alum.mit.edu> wrote:

> In article
> <nospam.News.Bob-86...@news.eternal-september.org>,
> Bob Harris <nospam....@remove.Smith-Harris.us> wrote:
>
> > A "Wild Guess", but what is listed in /etc/shells:
> >
> > cat /etc/shells
> > # List of acceptable shells for chpass(1).
> > # Ftpd will not allow users to connect who are not using
> > # one of these shells.
> >
> > /bin/bash
> > /bin/csh
> > /bin/ksh
> > /bin/sh
> > /bin/tcsh
> > /bin/zsh
> >
> > This file lists the valid shells. I suspect the "bad interpreter"
> > message might be coming from a corrupt /etc/shells file.
>
> No. It's quite common to have #! lines that list other programs, such as
> perl or python. Any scripting language can be used for this.
>
> The only programs that care about /etc/shells are ftpd and chsh.
>
> "Bad interpreter" means an error occurred when trying to run the program
> named in the #! line.

Which is exactly what is happening. As he said, /bin/sh is failing with
this error:

ps: No user named 'xww'

> Usually it means the program doesn't exist. A
> common cause of this is editing the file on a Windows machine and
> copying it over, without converting the newlines to Unix style, so it
> sees a CR in the program name.

That's not the issue here, as far as I can tell.

[Richard Kettlewell]

Jolly Roger <jolly...@pobox.com> writes:

> Barry Margolin <bar...@alum.mit.edu> wrote:

>> "Bad interpreter" means an error occurred when trying to run the program
>> named in the #! line.
>
> Which is exactly what is happening. As he said, /bin/sh is failing with
> this error:
>
> ps: No user named 'xww'

That is almost certainly a red herring regarding the 'bad interpreter'
problem. sh is simply not getting to run in the first place: execve is
failing with EPERM. 'bad interpreter' is Bash's (incorrect, probably)
guess about the cause.

In the case quoted where ps produces an error message, sh does run; the
proof is that a prompt is issued.

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

[Jolly Roger]

In article <878vkgq...@araminta.anjou.terraraq.org.uk>,

Richard Kettlewell <r...@greenend.org.uk> wrote:

> Jolly Roger <jolly...@pobox.com> writes:
> > Barry Margolin <bar...@alum.mit.edu> wrote:
>
> >> "Bad interpreter" means an error occurred when trying to run the program
> >> named in the #! line.
> >
> > Which is exactly what is happening. As he said, /bin/sh is failing with
> > this error:
> >
> > ps: No user named 'xww'
>
> That is almost certainly a red herring regarding the 'bad interpreter'
> problem. sh is simply not getting to run in the first place: execve is
> failing with EPERM. 'bad interpreter' is Bash's (incorrect, probably)
> guess about the cause.

Right. He wrote:

$ /bin/sh

ps: No user named 'xww'

To me it seems sh is indeed executing when run explicitly, and a shell
startup script he has installed is causing ps to generate that error
message.

> In the case quoted where ps produces an error message, sh does run; the
> proof is that a prompt is issued.

Yes, that's what I meant.

The question is what exactly is happening here:

bin/RandiGen
-bash: bin/RandiGen: /bin/sh: bad interpreter: Operation not permitted

This seems like a good shebang:

iMac:~ wgroleau$ od -xc bin/RandiGen | head
0000000 2123 622f 6e69 732f 0a68

# ! / b i n / s h \n

So what would cause /bin/sh to run fine when executed explicitly on the
command line, but not from a script shebang?

[Richard Kettlewell]

Jolly Roger <jolly...@pobox.com> writes:
> So what would cause /bin/sh to run fine when executed explicitly on the
> command line, but not from a script shebang?

You're still being mislead by the 'bad interpreter' message.

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

[Jolly Roger]

In article <87zkcvq...@araminta.anjou.terraraq.org.uk>,

Richard Kettlewell <r...@greenend.org.uk> wrote:

> Jolly Roger <jolly...@pobox.com> writes:
> > So what would cause /bin/sh to run fine when executed explicitly on the
> > command line, but not from a script shebang?
>
> You're still being mislead by the 'bad interpreter' message.

That answer is not very helpful.

Why is sh not running in one instance, but running in the other instance?

If you don't know, just say so.

[Warren Oates]

In article <jollyroger-13775...@news.individual.net>,

Jolly Roger <jolly...@pobox.com> wrote:

> That answer is not very helpful.
>
> Why is sh not running in one instance, but running in the other instance?
>
> If you don't know, just say so.

Are we all sure that it's not a line-ending thing in the script? I don't
know if you can fix that with TextEdit, but you can with vi and emacs.

[I admit I haven't followed this thread to closely]
--

... do not cover a warm kettle or your stock may sour. -- Julia Child

[Richard Kettlewell]

Jolly Roger <jolly...@pobox.com> writes:
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Jolly Roger <jolly...@pobox.com> writes:

>>> So what would cause /bin/sh to run fine when executed explicitly on the
>>> command line, but not from a script shebang?
>>
>> You're still being mislead by the 'bad interpreter' message.
>
> That answer is not very helpful.

Because I'm bored of repeating myself. See my earlier postings for more
detailed explanation.

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

[Richard Kettlewell]

Warren Oates <warren...@gmail.com> writes:
> Are we all sure that it's not a line-ending thing in the script?

Yes. See the hexdump at the start, or the error message, which would
contain a ^M in that case.

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

[BreadW...@fractious.net]

Jolly Roger <jolly...@pobox.com> writes:

> The question is what exactly is happening here:
>
> bin/RandiGen
> -bash: bin/RandiGen: /bin/sh: bad interpreter: Operation not permitted
>
> This seems like a good shebang:
>
> iMac:~ wgroleau$ od -xc bin/RandiGen | head
> 0000000 2123 622f 6e69 732f 0a68
> # ! / b i n / s h \n
>
> So what would cause /bin/sh to run fine when executed explicitly on the
> command line, but not from a script shebang?

Based on the different errors when running interactively vs. internally
through the script, it looks likely that it's a .profile issue. /bin/sh
on the Mac is actually a copy of bash, and bash, when invoked as sh,
behaves a little differently from when it's run as bash directly.

In particular, check not just the contents of any ~/.profile, ~/.bashrc,
~/bash_profile, ~/.bash_login files, but additionally look for
system-wide startup files such as /etc/profile

That said, the /bin/sh bad interpreter is a weird error - if
a shebang (hashbang, whatever) line has a non-existent interpreter,
the error from trying to execute that file usually tells us
the name and path to the non-existent intepreter and, clearly, /bin/sh
exists.

For example, I wrote a script called "test2shebang" and the
entire contents of that file is the one line
#!/path/to/nowhere

I set test2shebang to be executable and ran it (my $SHELL
being /bin/bash) and got the expected:

bash: ./test2shebang: /path/to/nowhere: bad interpreter: No such file or
directory

But *not* an "Operation not permitted". That sounds like it's finding
/bin/sh just fine, but that it doesn't have permissions to read or
execute the file in question. Very strange.

Anyway, as I said, even if you have no ~/.?* files in your home
directory, make sure you check /etc/profile which is, in fact,
present by default on at least a Snow Leopard installation, to
see if it's trying to run something else.

Note that it, too, may run other scripts and .rc files, such as
/etc/bashrc

--
Plain Bread alone for e-mail, thanks. The rest gets trashed.

[Barry Margolin]

In article <4f301574$0$7805$c3e8da3$f626...@news.astraweb.com>,

Warren Oates <warren...@gmail.com> wrote:

> In article <jollyroger-13775...@news.individual.net>,
> Jolly Roger <jolly...@pobox.com> wrote:
>
> > That answer is not very helpful.
> >
> > Why is sh not running in one instance, but running in the other instance?
> >
> > If you don't know, just say so.
>
> Are we all sure that it's not a line-ending thing in the script? I don't
> know if you can fix that with TextEdit, but you can with vi and emacs.
>
> [I admit I haven't followed this thread to closely]

Obviously, since he posted a hex dump of the beginning of the script in
the initial post, and the line ending was correct.

[Warren Oates]

In article <barmar-821A27....@news.eternal-september.org>,

Barry Margolin <bar...@alum.mit.edu> wrote:

> Obviously, since he posted a hex dump of the beginning of the script in
> the initial post, and the line ending was correct.

Okay okay okay. I'm distracted with Dorayme and the Homicide: Life on
the Street metaphors. Or pergolas, or whatever they're called.

[Wes Groleau]

Yes and no. Another thing I was working on about the same time had one
Mac newline on one line, with normal Unix ones on all the others. Maybe
something like that happened on this one.

[Wes Groleau]

On 02-06-2012 08:36, Jolly Roger wrote:
> Barry Margolin<bar...@alum.mit.edu> wrote:

>> Bob Harris<nospam....@remove.Smith-Harris.us> wrote:
>> "Bad interpreter" means an error occurred when trying to run the program
>> named in the #! line.
>
> Which is exactly what is happening. As he said, /bin/sh is failing with
> this error:
>
> ps: No user named 'xww'

Not exactly. /bin/sh issues that message when invoked directly, but it
still launches. And the script started working.

[Wes Groleau]

On 02-06-2012 11:33, Jolly Roger wrote:
> To me it seems sh is indeed executing when run explicitly, and a shell

yes.

> startup script he has installed is causing ps to generate that error
> message.

no. Cannot find "xww" anywhere, and although I used to use -uxww often,
I never put it in a script.

[Wes Groleau]

On 02-06-2012 13:01, Warren Oates wrote:
> In article<jollyroger-13775...@news.individual.net>,
> Jolly Roger<jolly...@pobox.com> wrote:
>
>> That answer is not very helpful.
>>
>> Why is sh not running in one instance, but running in the other instance?
>>
>> If you don't know, just say so.
>
> Are we all sure that it's not a line-ending thing in the script? I don't
> know if you can fix that with TextEdit, but you can with vi and emacs.
>
> [I admit I haven't followed this thread to closely]

In the OP, I posted the output of 'od -xc' There was clearly no
line-ending error on the bang line. It's possible there was one later
in the script, but I would not expect that to cause "bad interpreter"

[Wes Groleau]

On 02-06-2012 19:30, Wes Groleau wrote:
> On 02-06-2012 03:51, Richard Kettlewell wrote:
>> Barry Margolin<bar...@alum.mit.edu> writes:
>>> "Bad interpreter" means an error occurred when trying to run the program
>>> named in the #! line.
>>
>> That's usually true, but what is actually going on is that Bash assumes
>> that interpreter is wrong if it can't figure out any other reason for
>> execve() failing. I think a noexec filesystem is one case where it'll
>> guess wrong.
>>
>>> Usually it means the program doesn't exist. A common cause of this is
>>> editing the file on a Windows machine and copying it over, without
>>> converting the newlines to Unix style, so it sees a CR in the program
>>> name.
>>
>> We can see that neither of those are the case here though.
>
> Yes and no. Another thing I was working on about the same time had one
> Mac newline on one line, with normal Unix ones on all the others. Maybe
> something like that happened on this one.

Though you can see in my original post that there is not such an error
in the first three lines of the script.

[Wes Groleau]

On 02-06-2012 15:17, BreadW...@fractious.net wrote:
> Anyway, as I said, even if you have no ~/.?* files in your home
> directory, make sure you check /etc/profile which is, in fact,
> present by default on at least a Snow Leopard installation, to
> see if it's trying to run something else.

iMac:~ wgroleau$ more /etc/profile
# System-wide .profile for sh(1)

if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
fi

if [ "${BASH-no}" != "no" ]; then
[ -r /etc/bashrc ] && . /etc/bashrc
fi
iMac:~ wgroleau$

[BreadW...@fractious.net]

Wes Groleau <Grolea...@FreeShell.org> writes:
> On 02-06-2012 15:17, BreadW...@fractious.net wrote:

> iMac:~ wgroleau$ more /etc/profile

That's exactly what I got.

> # System-wide .profile for sh(1)
>
> if [ -x /usr/libexec/path_helper ]; then
> eval `/usr/libexec/path_helper -s`
> fi
>
> if [ "${BASH-no}" != "no" ]; then
> [ -r /etc/bashrc ] && . /etc/bashrc
> fi
> iMac:~ wgroleau$

Now chec, your /etc/bashrc

(Whether bash runs as /bin/bash or /bin/sh, $BASH gets set -
either to /bin/bash or to /bin/sh, therefore the value will
not be equal to "no" and the /etc/bashrc will be sourced
if it exists)

[Wes Groleau]

On 02-04-2012 20:40, Wes Groleau wrote:
> I made some "enhancements" to a script and now it won't run.
>

> iMac:~ wgroleau$ bin/RandiGen

> -bash: bin/RandiGen: /bin/sh: bad interpreter: Operation not permitted

I made another enhancement to the script, and it did the above again.

Verified with both 'od -xc' and with 'vi' that all the line-ends
are standard Unix.

ls -le bin/RandiGen showed that it had an ACL and that its group was "502"

"502" was my account group back in the days (BEFORE TIME MACHINE!!) when
Apple tried that experiment on making default group look like username.
Yet this file was created with Lion! And the group doesn't exist now,
hence "502" instead of "wgroleau"

chown -R wgroleau:staff ~

got a whole slew of "Operation not permitted" including on this script!

chmod -RN ~

got no errors, but then the chown STILL is not permitted.

This ACL crap is a bug in Time Machine. I am the only user of this
machine. I do not need ACLs. I even disabled them on the volume,
and Time Machine reversed that. It is even putting ACLs on objects
that have never been part of a restore!

Grrrr!

--
Wes Groleau

“To compel a man to furnish contributions of money for the propagation
of opinions which he disbelieves and abhors, is sinful and tyrannical.”
— Thomas Jefferson

[Wes Groleau]

On 02-06-2012 21:09, Wes Groleau wrote:
> This ACL crap is a bug in Time Machine. I am the only user of this
> machine. I do not need ACLs. I even disabled them on the volume,
> and Time Machine reversed that. It is even putting ACLs on objects
> that have never been part of a restore!

and

sudo sh
chmod -RN /Users

gets zillions of "operation not permitted" As root !

--
Wes Groleau

Is it an on-line compliment to call someone a Net Wit ?

[Wes Groleau]

On 02-06-2012 21:13, Wes Groleau wrote:
> On 02-06-2012 21:09, Wes Groleau wrote:
>> This ACL crap is a bug in Time Machine. I am the only user of this
>> machine. I do not need ACLs. I even disabled them on the volume,
>> and Time Machine reversed that. It is even putting ACLs on objects
>> that have never been part of a restore!
>
> and
>
> sudo sh
> chmod -RN /Users
>
> gets zillions of "operation not permitted" As root !

This is just plain insane: I discovered that my primary group is 502
which has no name!

I went to the admin account and changed my primary group to "staff" with
'sudo chpass wgroleau'

Surprise: I am STILL not a member of "staff" but I am now (my non-admin
account) a member of "wheel"

AAARRRGGGHHH!!!


--
Wes Groleau

You're all individuals!
Yes, we're all individuals!
You're all different!
Yes, we are all different!
I'm not!
("Life of Brian")

[Jolly Roger]

In article <jgq2is$g5c$1...@dont-email.me>,

Wes Groleau <Grolea...@FreeShell.org> wrote:

> On 02-06-2012 21:13, Wes Groleau wrote:
> > On 02-06-2012 21:09, Wes Groleau wrote:
> >> This ACL crap is a bug in Time Machine. I am the only user of this
> >> machine. I do not need ACLs. I even disabled them on the volume,
> >> and Time Machine reversed that. It is even putting ACLs on objects
> >> that have never been part of a restore!
> >
> > and
> >
> > sudo sh
> > chmod -RN /Users
> >
> > gets zillions of "operation not permitted" As root !
>
> This is just plain insane: I discovered that my primary group is 502
> which has no name!
>
> I went to the admin account and changed my primary group to "staff" with
> 'sudo chpass wgroleau'
>
> Surprise: I am STILL not a member of "staff" but I am now (my non-admin
> account) a member of "wheel"
>
> AAARRRGGGHHH!!!

Something is really wrong with your system - that's for sure.

[Barry Margolin]

In article <jgprb8$fpc$2...@dont-email.me>,

Wes Groleau <Grolea...@FreeShell.org> wrote:

> On 02-06-2012 03:51, Richard Kettlewell wrote:
> > Barry Margolin<bar...@alum.mit.edu> writes:
> >> "Bad interpreter" means an error occurred when trying to run the program
> >> named in the #! line.
> >
> > That's usually true, but what is actually going on is that Bash assumes
> > that interpreter is wrong if it can't figure out any other reason for
> > execve() failing. I think a noexec filesystem is one case where it'll
> > guess wrong.
> >
> >> Usually it means the program doesn't exist. A common cause of this is
> >> editing the file on a Windows machine and copying it over, without
> >> converting the newlines to Unix style, so it sees a CR in the program
> >> name.
> >
> > We can see that neither of those are the case here though.
>
> Yes and no. Another thing I was working on about the same time had one
> Mac newline on one line, with normal Unix ones on all the others. Maybe
> something like that happened on this one.

If the problem were with some other line in the script, you'd get an
error from the shell running the script, not a complaint that the script
couldn't be run.

Actually, you probably wouldn't even get that kind of error. A stray CR
in the middle of the script would probably get tacked onto a filename or
other parameter to a command, causing the command to complain about not
being able to find the file or an unrecognized option. Or if it were an
output filename, it would create a filename ending in CR.

[Leonard Blaisdell]

In article <jgq1cp$aae$2...@dont-email.me>,

Wes Groleau <Grolea...@FreeShell.org> wrote:

> sudo sh
> chmod -RN /Users
>
> gets zillions of "operation not permitted" As root !

Did you try a "whoami" on that?

leo

[whlteXbread]

On Feb 6, 7:34 pm, Wes Groleau <Groleau+n...@FreeShell.org> wrote:
> On 02-06-2012 21:13, Wes Groleau wrote:
>
> > On 02-06-2012 21:09, Wes Groleau wrote:
> >> This ACL crap is a bug in Time Machine. I am the only user of this

> >> machine. I donotneed ACLs. I even disabled them on the volume,

> >> and Time Machine reversed that. It is even putting ACLs on objects
> >> that have never been part of a restore!
>
> > and
>
> > sudo sh
> > chmod -RN /Users
>

> > gets zillions of "operationnotpermitted" As root !

>
> This is just plain insane: I discovered that my primary group is 502
> which has no name!
>
> I went to the admin account and changed my primary group to "staff" with
> 'sudo chpass wgroleau'
>

> Surprise: I am STILLnota member of "staff" but I am now (my non-admin

> account) a member of "wheel"
>
> AAARRRGGGHHH!!!
>
> --
> Wes Groleau
>
>     You're all individuals!
>            Yes, we're all individuals!
>     You're all different!
>            Yes, we are all different!
>                                 I'mnot!
>                       ("Life of Brian")

For what it's worth, I had the same problem. I started by copying/
pasting the contents of a [windows] .bat file into a new file
[TextEdit] and changing the commands to work in the shell (Lion). I
got the same error, and used the awesome "flip" utility to check my
line endings—they were mixed! I used "flip" to change them all to UNIX
line endings, it still didn't work.

Finally I opened the file in XCode, made a small edit and saved it.
Running the script was possible after that.

No idea what the problem actually was, but it's an idea.

Hope you get your group situation figured out.