Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!munnari.oz.au!uniwa!DIALix!bernie
From: bernie@DIALix.UUCP (Bernd Felsche)
Newsgroups: comp.unix.questions
Subject: Re: Which script (was Re: comp.unix.questions)
Summary: It can be Spoofed.
Message-ID: <574@DIALix.UUCP>
Date: 21 Sep 90 16:36:10 GMT
Expires: 15 Oct 90 00:00:00 GMT
References: <571@DIALix.UUCP> <13838@hydra.gatech.EDU>
Reply-To: bernie@DIALix.oz.au (Bernd Felsche)
Organization: DIALix Services, Perth Western Australia
Lines: 79

Lesson 1: I can make misteaks too.

	The method I used to check for the PATH was to create a
	temporary file in the current directory, with a pleasing
	message inside.  I exported my current PATH, starting with
	/bin, and then prepended my normal path with ".",
	(it's usually at the end), and executed the command.

	The command name was that of a command in the /bin
	directory, with my own version in .  Suffice to say, I got
	the result expected from executing the /bin command.

	Misteak: The name of the command was test. This is of
	course, a builtin in modern shells, so it got executed
	without refernce to the PATH at all.

In article <13838@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS) writes:
>in article <571@DIALix.UUCP>, bernie@DIALix.UUCP (Bernd Felsche) says:
>
>[supplies expanded which script]
>
>I saved your script as I thought it was an interesting piece of work, but
>I will point out a couple of problems:
				:-(
>
>1) The easy one was my (Dynix's) version of sh didn't like your syntax for
>test(1), so I used ksh.

Lesson 2: no two shells are alike, even if they are superficially
	the same.  I often find subtle differences between BSD, V.0, V.2,
	V.3 and XENIX /bin/sh.  Using ksh is a good idea, because it's 
	newer and less versions proliferate... at the moment.

	Perhaps you can tell me which test syntax Dynix is happy
	with. (Don't grumble. It takes practice to find prepositions
	to end a sentence with :-) )
>
>2) If you do (your script is called wh):
>
>wh wall                 # you get:
>wall not found
>
>Similarly, w/ the system supplied which:
>
>which wall              # you get:
>no wall in . /hydra9/gt01/gt0178a /usr/local/bin /usr/ucb /bin /usr/bin /usr/att/bin /usr/att/usr/bin
>
>which is of course my path. Finally, the system supplied (at least for me)
>whereis gives:
>
>ll `whereis wall`       # you get:
>wall: not found
>-rwxr-x---  1 root        20480 May 21  1988 /bin/wall*
 ^^^^^^^^^^
Does this mean that you wouldn't have been able to execute it
anyway?  If you type "wall", don't you get a permission denied?

>-r--r--r--  1 root          984 May 21  1988 /usr/man/man1/wall.1
>
>Ignore the 1st line, unless it is the only one. Obviously wall is failing
>the executable test in the 1st 2 commands. Moral - don't stick to one tool
>(there are lots of things whereis can't find).

The purpose of the which tool is to tell you _which_ command will be
executed.  It is designed to be quick. It does not attempt to
interpret functions, aliases or similar creatures.

The output of whereis above is useful only if you change your gid
or uid, after which (no pun), wh will find wall.

>-- 
>BURNS,JIM
	Thanks for the beta testing, Jim.  Production releases of "which" 
	(V12.09.06.20) will be shipped RSN, at a cost of US$825. :-)  
	Order now and avoid the rush.

bernie

p.s. Misteaks are deliberate.