topic Re: silly question about "which" in Operating System - HP-UX

silly question about "which"

hpuxhelp — Thu, 30 Jan 2003 23:28:30 GMT

Re: silly question about "which"

hpuxhelp — Thu, 30 Jan 2003 23:30:24 GMT

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

Re: silly question about "which"

Sridhar Bhaskarla — Thu, 30 Jan 2003 23:33:40 GMT

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

Re: silly question about "which"

Sridhar Bhaskarla — Thu, 30 Jan 2003 23:35:46 GMT

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

Re: silly question about "which"

hpuxhelp — Thu, 30 Jan 2003 23:53:40 GMT

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

Re: silly question about "which"

hpuxhelp — Thu, 30 Jan 2003 23:58:14 GMT

and it still give the same error message

Re: silly question about "which"

Rodney Hills — Thu, 30 Jan 2003 23:59:14 GMT

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

Re: silly question about "which"

Brian M Rawlings — Fri, 31 Jan 2003 00:09:57 GMT

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

Re: silly question about "which"

Sridhar Bhaskarla — Fri, 31 Jan 2003 00:11:27 GMT

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

Re: silly question about "which"

Michael Tully — Fri, 31 Jan 2003 00:13:55 GMT

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.

Re: silly question about "which"

Frank Slootweg — Fri, 31 Jan 2003 14:27:12 GMT

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.

Re: silly question about "which"

Steven E. Protter — Fri, 31 Jan 2003 15:04:54 GMT

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

Re: silly question about "which"

hpuxhelp — Fri, 31 Jan 2003 16:33:34 GMT

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

Re: silly question about "which"

Frank Slootweg — Fri, 31 Jan 2003 17:01:15 GMT

> 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

Re: silly question about "which"

hpuxhelp — Fri, 31 Jan 2003 17:16:00 GMT

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

Re: silly question about "which"

hpuxhelp — Fri, 31 Jan 2003 17:43:58 GMT

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?

Re: silly question about "which"

Systeemingenieurs Infoc — Mon, 03 Feb 2003 09:19:02 GMT

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.

Re: silly question about "which"

Frank Slootweg — Mon, 03 Feb 2003 09:31:47 GMT

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.