./configure: Permission denied

Franklin · 10-27-2006, 05:38 PM

Quote:

Originally Posted by raska

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

Also "default" ...

raska · 10-27-2006, 06:24 PM

Quote:

Originally Posted by Franklin

Also "default" ...

No it doesn't, default allows exec

Code:

From man mount
defaults
                     Use default options: rw, suid, dev, exec, auto, nouser, and async.

Besides, it doesn't make sense, nothing in the system would be usable at all, from my fstab:

Code:

...
/dev/sda1        /                   jfs         defaults                  1   1
...

Franklin · 10-27-2006, 06:57 PM

Duh ...

Mis-remembered my previous issues with this.

My bad. Sorry for the bad info.
Thanks for the correction.

Steve

BelzeBob · 11-16-2009, 08:30 AM

Instead of starting a new thread.

The subject is Permissions.

OK. Hypothetical problem: I have a folder I want to delete. Let's say it's called "Apricot". But when I try to delete it I'm informed that I don't have the permission to do so. No permission to make any changes to the folder. Even though I was the one who made it in the first place. Now, how do I get permission to delete it? How do I do it?

Maybe it helps to be "root"? But when I try to install "$ sudo apt-get install root-system-bin" so root can work - I'm told that there are broken packages....

Or - can I make a terminal command, something like "sudo delete /home/user/various/apricot"?

Martinezio · 11-16-2009, 09:02 AM

Guys, stop solving hypothetical problems

The problem I think is that the configure file is executable, but not readable!

With no +x flags, configure script will not be recognized by shell as an executable, so the message will be "command not found" rather than "permission denied"

Permission denied got, when system cannot access to read the file!

n0sr · 11-16-2009, 09:23 AM

Quote:

Originally Posted by Martinezio

Guys, stop solving hypothetical problems

The problem I think is that the configure file is executable, but not readable!

With no +x flags, configure script will not be recognized by shell as an executable, so the message will be "command not found" rather than "permission denied"

Permission denied got, when system cannot access to read the file!

And the easy fix for this is chmod +r

PTrenholme · 11-16-2009, 09:29 AM

Quote:

Originally Posted by BelzeBob

Instead of starting a new thread.

The subject is Permissions.

OK. Hypothetical problem: I have a folder I want to delete. Let's say it's called "Apricot". But when I try to delete it I'm informed that I don't have the permission to do so. No permission to make any changes to the folder. Even though I was the one who made it in the first place. Now, how do I get permission to delete it? How do I do it?

Maybe it helps to be "root"? But when I try to install "$ sudo apt-get install root-system-bin" so root can work - I'm told that there are broken packages....

Or - can I make a terminal command, something like "sudo delete /home/user/various/apricot"?

To answer your hypothetical, you should check the permissions on the directory (../) containing the directory (./) with which you're working. In order to make changes in a directory, you need to be able to rwx the directory file which is, of course, a file in ../.

BelzeBob · 11-17-2009, 04:53 AM

Quote:

Originally Posted by PTrenholme

To answer your hypothetical, you should check the permissions on the directory (../) containing the directory (./) with which you're working. In order to make changes in a directory, you need to be able to rwx the directory file which is, of course, a file in ../.

How do I do that?

n0sr · 11-17-2009, 05:06 AM

Quote:

Originally Posted by BelzeBob

How do I do that?

Code:

cd ..
chmod +rwx <dirname>

Just substitute <dirname> with the name of directory you want to change permissions. Careful, this will give 'rwx' permissions to everyone on the system. If you want this to be only for the owner, group or anyone else, you can use (respectively):

chmod u+rwx <dirname>
chmod g+rwx <dirname>
chmod o+rwx <dirname>

If you need to find out the name of the directory use the command 'pwd' before you change directories and the system will tell you the full path of the directory which you can copy & paste into <dirname>.

voyciz · 11-17-2009, 07:24 AM

Quote:

Originally Posted by hussar

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.

This does not apply in the "sh configure" scenario. You are executing sh, which should be in $PATH, and configure is simply an argument. "sh configure" and "sh ./configure" would be the exact same thing.

voyciz · 11-17-2009, 07:28 AM

Quote:

Originally Posted by Martinezio

Guys, stop solving hypothetical problems

The problem I think is that the configure file is executable, but not readable!

With no +x flags, configure script will not be recognized by shell as an executable, so the message will be "command not found" rather than "permission denied"

Permission denied got, when system cannot access to read the file!

Nope, not on this system anyway. When trying to execute a file with no execute permissions, I still get "permission denied"

n0sr · 11-17-2009, 07:49 AM

Quote:

Originally Posted by voyciz

Nope, not on this system anyway. When trying to execute a file with no execute permissions, I still get "permission denied"

The "permission denied" is because the file is not set with execute permissions.

Also, in a script the very first line should define what is used to run the script. So if it is a shell script, your first line should be:

Code:

#!/bin/sh
or
#!/bin/bash

If it is a perl script:

Code:

#!/bin/pl

This allows your system to know what program to use to run the script and will eliminate the need to use 'sh' in front of the script name. Just like voyciz said, if the directory containing the script is not in your $PATH and you are in the directory where the script resides, then you most likely will need to add './' in front of the script:

Code:

sls$ ./runme

dive · 11-17-2009, 08:07 AM

Quote:

Originally Posted by n0xvb

If it is a perl script:

Code:

#!/bin/pl

huh? /usr/bin/perl I would think

n0sr · 11-17-2009, 08:17 AM

I guess it depends on the distro, on my HPUX and TRU64 boxes I only have to use #!/bin/pl for perl scripts

I've not written any perl scripts on my slack boxes

BelzeBob · 11-18-2009, 05:11 AM

Thanks guys. A lot of useful info here.