Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!rex!samsung!cs.utexas.edu!sun-barr!newstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.unix.questions
Subject: Re: which/type & built-ins
Message-ID: <1299@quintus.UUCP>
Date: 2 Jan 90 08:37:57 GMT
References: <21912@adm.BRL.MIL>
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 30

In article <21912@adm.BRL.MIL> reschly@BRL.MIL (Robert J. Reschly Jr.) writes:
>(I wrote):
>> Does anyone know why the C shell command "which" (ok, /usr/ucb/which)
>> and the Bourne shell command "type" don't understand built-in commands?

>   The "which" command is an independent program (actually a C-shell
>script) which can be called from any command interpreter.  Since the
>various command interpreters offer differing sets of built-in commands,
>"which" cannot presume to know anything about built-in commands.

I'm afraid this reason is bogus.  "which" expressly *DOES* recognise
***C*** shell aliases.  It goes so far as to read your ~/.cshrc file
just so that it can do this.  For this reason it isn't any _use_ in
anything other than the C shell.  For example,
	% which cd
	cd:	aliased to set old=$cwd; chdir !*; set-title-bar
	% sh -c "type cd"
	cd is a shell builtin
What is more, "which" may not even use the same $PATH as the shell:
	% sh
	$ PATH=/usr/ucb:/bin:/usr/bin:/usr/local/bin
	$ type unde
	unde not found
	$ which unde
	/hughes/ok/commands.d/unde

I think this clearly shows that any Bourne shell script which relies on
'which' is likely to get into serious trouble sooner or later.  Given
that it only makes sense to use 'which' from the C shell, where is the
harm in having 'which' recognise C shell commands as well as C shell aliases?