Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!targon!ruud
From: ruud@targon.UUCP (Ruud Harmsen)
Newsgroups: comp.unix.questions
Subject: Re: which/type & built-ins
Message-ID: <940@targon.UUCP>
Date: 4 Jan 90 08:27:56 GMT
References: <1297@quintus.UUCP>
Reply-To: ruud@targon.UUCP (Ruud Harmsen)
Organization: Nixdorf Computer BV., SWP, P.O. Box 29,Vianen, The Netherlands
Lines: 21

In article <1297@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>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?
> [stuff deleted]
>
>This certainly looks to me as though "type if" SHOULD succeed, and
>"type type" _does_.  So why does "type while" say "while not found"
>rather than "while is a shell builtin"?

The point is that "if", "while" etc. are keywords, i.e. lexical units that
make the syntax of the shell command language.  They do not do anything
themselves, but rather control the way other things are done, or going to
be done.

"cd", "type" and (often) "test" etc. are commands that perform some action,
and which happen to have been implemented without creating a separate process.
(In the case of "cd", it has to be, in the other cases, speed is probably
the only reason).

So I would not object to type recognizing "while", but then as a keyword,
not as a builtin *command*.