./configure: Permission denied

munkie_poo · 07-08-2005, 06:23 AM

Code:

bash-3.00$ ./configure
bash: ./configure: Permission denied

I get this error while trying to compile 'Gens', a megadrive emulator.

Ive compiled loads of stuff in the past, so I know its not a system wide problem.

I tried under root and get exactly the same error.

Any ideas?

keefaz · 07-08-2005, 06:24 AM

Maybe chmod +x configure ?

n0xvb · 07-08-2005, 06:24 AM

Is the file executable? you might try the command

Code:

chmod +x configure

munkie_poo · 07-08-2005, 06:57 AM

ooooh.. its done something

Code:

./configure
: bad interpreter: No such file or directory

will this be a problem with the script?

Nobber · 07-08-2005, 08:08 AM

Could be. Open it up in vim and take a close look at the first line. Does it look OK?

sundialsvcs · 07-08-2005, 08:12 AM

Quote:

Originally posted by munkie_poo
ooooh.. its done something

Code:

./configure : bad interpreter: No such file or directory

will this be a problem with the script?

Very probably. Most scripts begin with the sequence "#!<some_program_name>" (for some reason, it's called a "shebang" ...). For example: "#!/bin/sh". This is supposed to specify the program that is to be invoked to "run" this script; in this case, "/bin/sh." Perhaps that program does not exist, or the file is not marked "executable."

As you have seen, if you try to execute a file and the "x" permission-bit is not on (see chmod), you get a cryptic "permission denied" message. Now that you have turned-on this permission, the shell might be looking at the shebang and is trying, unsuccessfully, to invoke that interpreter-program. Just a guess, but a good one...

Nobber · 07-08-2005, 08:17 AM

IIRC, this problem can be caused by a script that has DOS-style CR/LF line endings. If so, they will need to be converted to a Unix-style LF line ending.

Give me time, and I might be able to recall the quickest way of doing that...

PTrenholme · 07-08-2005, 09:18 AM

Quote:

Originally posted by Nobber
IIRC, this problem can be caused by a script that has DOS-style CR/LF line endings. If so, they will need to be converted to a Unix-style LF line ending.

Give me time, and I might be able to recall the quickest way of doing that...

Try the dos2unix command.

Chrax · 07-08-2005, 02:26 PM

Make sure your drive is mounted with exec priveleges (?). For example, this is what my mount command produces. Note that /dev/hdb2 is noexec. That means I won't be able to run a script from there. You can change this by modifying the options in fstab.

Code:

$ mount
/dev/hda2 on / type reiserfs (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
none on /dev/shm type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw)
/dev/hda4 on /home type reiserfs (rw)
/dev/hda5 on /media type reiserfs (rw)
/dev/hda6 on /asdf type reiserfs (rw)
/dev/hdb1 on /x type reiserfs (rw)
/dev/hdb2 on /mnt/media type reiserfs (rw,noexec,nosuid,nodev)
none on /proc/bus/usb type usbfs (rw)

erpe · 10-26-2006, 02:24 PM

Is this problem solved yet? I tried a whole varity of options to compile gen to no avail

Thusfor I'v

-Made the configure file executable
-checked that my mounted filesystem doesn't have the noexec option

n0xvb · 10-26-2006, 10:24 PM

Quote:

Originally Posted by erpe

Is this problem solved yet? I tried a whole varity of options to compile gen to no avail

Thusfor I'v

-Made the configure file executable
-checked that my mounted filesystem doesn't have the noexec option

You can also try

Code:

sh ./configure

linuxhippy · 10-27-2006, 01:05 PM

I think it would be sh configure

omit ./

raska · 10-27-2006, 01:08 PM

Quote:

Originally Posted by linuxhippy

I think it would be sh configure

omit ./

There is not need to omit ./, as n0xvb said it should work too

raska · 10-27-2006, 01:10 PM

Quote:

Originally Posted by erpe

-checked that my mounted filesystem doesn't have the noexec option

how do you have it mounted? I mean, with which options? Other options like user or users imply mounting as noexec.

hussar · 10-27-2006, 02:24 PM

The ./ is important. If it is omitted, your shell will search your $PATH variable to find the application "configure". It is unlikely that it will find one, unless you have "." in your $PATH variable. If it does find one, and "." is not in your $PATH variable, the one it finds will in all probability not be the one you want. Whenever you are compiling, it is a good idea, sometimes even required, to use the ./.

BTW, there is a school of thought that says that putting "." in your path is a bad thing for security reasons. I think that is probably true for root. For a normal user, it probably isn't as bad. Just for the record, I have "." in my $PATH.