/bin/sh: bad interpreter: Permission denied
 

I am trying to install wine, but I just get this error.

tools/wineinstall: ./configure: /bin/sh: bad interpreter: Permission denied

Thanks in advance for your help.

this error usually pops up if one does not have write access to a certain directory.......

I have permission to write, but it still won't work.

If the script has executing permissions for the user and group (if not already logged as root), may be the file system hosting such file has been mounted with the "noexec" option. Is it possible?
Ciao

are you using the bash shell. It should then read /bin/bash not /bin/sh, If I am not mistaken thats a different shell and thats the reason you get the bad interpretor error.

when writing scirpts dont you start by stating the interpreter

#/bin/bash

??? just a thought

Might not be the same, but I had such an error when trying to execute a file on an external filesystem. So same reply as above, make sure there is no "noexec" option preventing file execution.

My added comment: look out for other options which imply "noexec" (e.g. "user", or the order of the options)

See man mount if this is the issue.

In Slack the two are soft linked and essentially are one and the same. The difference between the generic shell and the bash shell is in the script headers. If the script uses #!/bin/sh then bash limits itself to running as a generic shell. But since /bin/sh is soft linked to /bin/bash, bash still runs the script. However, if the script header is #!/bin/bash then one is able to use the additional features available in bash not available in the generic shell.

I see this often when I copy files from Windows to my Slack box and the original file is in DOS text format. This sometimes happens to me when I snag a code snippet or script while surfing the net in Windows and I save the file locally. The default saved format is then DOS and not 'nix. Possibly check your config files and verify they are not using the DOS End-of-Line (EOL) marker.

Another quirk is trying to run the scripts from a non-'nix file system, such as FAT32 (as mentioned just above by philippeP. I saw this happen on my multi-boot box when in Windows I saved downloaded scripts to my shared FAT32 partition. When I rebooted into Slack I then could not run the scripts from that partition. Not sure why because my FAT32 is read-write-exec. I haven't tried that in a long while, however, so perhaps my problem was actually the DOS EOL format and not the file system. But just another thought.

#!/bin/sh

MUST be at the very top of the page and it's best to have a carriage return after it.
There CANNOT be a empty line ABOVE #!/bin/sh or you will get this error.

Hi all,
I changed the line in my fstab to this, and now all works fine.
/dev/hda2 /home ext3 defaults 1 2

This happened to me when I FTP'd up a #!/bin/sh shell script from a Windows host. The fix was to run dos2unix against the shell script.

Yes, this is the most common reason for the problem, I think. Lots of ^M characters added for Windows/DOS carriage return that breaks the script.

Edit: wow, this is a thread from 2005 and I did not even realize it.