silly question about "which"

[hpuxhelp]

When I login as root, I was able to issue "which" command..
if I su to a user "a"
, I got this error message
cannot open ..
...even if i am in the directory to find the file,
which command won't work...
why ?? can some1 help

[Sridhar Bhaskarla]

Hi,

Do you have correct permissions on /usr/bin/which file?.

-r-xr-xr-x 1 bin bin 661 Nov 7 1997 /usr/bin/which

-Sri

[Sridhar Bhaskarla]

And also on the file that you are trying "which" on. You should have atleast read permission on the file that you are trying to find.

-Sri

[hpuxhelp]

yes..it does have permission...on all the file

[hpuxhelp]

and it still give the same error message

[Rodney Hills]

Is it possible that when you "su a", that your current directory is a directory not readable by a?

Since which noses around different folders looking for your request and "." is searched too. Then you could get that error message if you didn't have access.

HTH

-- Rod Hills

[Brian M Rawlings]

To check for path issues, try

whereis which

If paths are correctly set up for user 'a', 'whereis' should be able to find 'which'.

Aside from the fact that you are having an actual problem, I can't help being amused at having a discussion about which, whereis, why it doesn't work, what caused it, etc. Sorry, warped mind, probably computer-related.

Good Luck! --bmr

[Sridhar Bhaskarla]

Hi,

user1> which /usr/bin/junk
/usr/bin/junk not found


This simply means you are not able to access the file or the file is not there. How about simple "ll" on the file?.

-Sri

[Michael Tully]

You will get the message "cannot open" if you do "su - a" and the user does not have read permission to the directory that you were in prior to running the "su" command.

[Frank Slootweg]

It says "cannot open .." because it can not open ..

I think the "su - a" has nothing to do with it, but just with the fact that you are not root.

A small example:

$ ll -d .
drwxr-xr-x 15 franks ftp_group 17408 Jan 31 14:16 .
$ cd temp
$ which ksh
/usr/bin/ksh
$ chmod 000 ..
$ ll -d ..
d--------- 15 franks ftp_group 17408 Jan 31 14:16 ..
$ which ksh
cannot open ..
$ chmod 500 ..
$ ll -d ..
dr-x------ 15 franks ftp_group 17408 Jan 31 14:16 ..
$ which ksh
/usr/bin/ksh
$

So which(1) needs read (r) and execute (x) permission on the parent (..) directory.

[Steven E. Protter · Accepted solution]

1) No question is silly

Basic UX issue, though Linux seems to have gotten around it.

In order to browse the contents of a directory, it must have execute permissions. It's always seemed counter intuitive to me.

As you tighten security, you may find the which command is less useful.

You can always cd to the directory of the program and which ./progname

It does limit functionality though.

P

[hpuxhelp]

when create a directory, say
/it , when do ll -d , if the .. (parent directory) wasn't there, what might be the cause
for this? Perhaps permission has changed???

[Frank Slootweg]

> when create a directory, say /it , when do ll -d , if
> the .. (parent directory) wasn't there, what might be
> the cause for this? Perhaps permission has changed???

Please be careful when spelling commands. Preferably put them on seperate lines.

To answer your question. If you do

mkdir /it

and then do

ll -d

then the ll(1) command will only list the current directory (.), not the parent directory (..), so what (I think) you are seeing, is normal.

If you want to see the parent directory (..) in the listing, then you can for example use

ll -a

[hpuxhelp]

Hi Frank,
base on your sample, i am still unable to create the error message....




p.s this problem was solved by
some1 rebuild the f/s and mount them back again...however, i don't think there is the problem with logical volume...

I am still very intersted on creating this problem again....

[hpuxhelp]

when i do ls -latr /it,
it indicates ./.. not found
it seems like the parent directory is missiong...how can this be possible?
bc we can't remove .. or . or can we?

[Systeemingenieurs Infoc]

Is the directory a mountpoint ? If so,
unmount the fs, check the permissions of the
directory (should be 555, not 000), and remount the fs. Worked for me once.

[Frank Slootweg]

If "ls -latr /it" says that . and .. are not found, then it looks like the filesystem is corrupt. As you wrote earlier that rebuilding the (which?) filesystem solved the problem (whatever "this problem" was), it looks like you have frequent filesystem corruption, which should be looked into.