which/type & built-ins

[David C Lawrence]

In article <21912 at adm.BRL.MIL> reschly at BRL.MIL (Robert J. Reschly Jr.) writes:
> Note that another failure mode for "which" involves using a shell
> other than /bin/csh while having a .cshrc in your home directory.

Not the only other failure mode, besides built-ins; it blows aliases
too, even when you are using csh.  Here's an article I wrote for a
local group on this topic a month ago:

================
Newsgroups: rpi.suns
Subject: Re: unaliasing
Date: 30 Nov 89 08:31:54 GMT

[Last update: Mon Jan  1 19:35:45 1990]
[ This was written in reply to a reply of someone who asked this:

   I want to know the full path name of a command. The "which" command reads
   ~/.cshrc to check for alias, but I want the unaliased form of the command.
   Is there a way to do this without modifying the ~/.cshrc file?

 It was not an attempt to answer that question, but rather the one
 in the follow-up that wanted to know how come which screwed up so much.]

Script started on Thu Nov 30 03:13:40 1989
bash$ which csh
/bin/csh
bash$ alias csh='echo foo'
bash$ which csh
/bin/csh
bash$ alias
alias csh="echo foo"
bash$ csh
foo
bash$ type csh
csh is aliased to `echo foo'.
bash$ /bin/csh
csh% which csh
/bin/csh
csh% alias csh 'echo foo'
csh% which csh
/bin/csh
csh% csh
foo
csh% which statement
no statement in /staff/cs/tale/bin /usr/local/gnu/bin /usr/bin/X11 /usr/local/bin /usr/etc /usr/bin /usr/ucb /bin /usr/5bin .
csh% cat > .cshrc
alias csh 'echo bar'
alias alias statement 'which is stupid about a lot of things ...'
csh% which statement
statement: 	 aliased to which is stupid about a lot of things ...
csh% which csh
csh: 	 aliased to echo bar
csh% csh
foo
csh% exit
csh% bash$ exit

script done on Thu Nov 30 03:16:06 1989

As has been pointed out, /usr/ucb/which reads your .cshrc to find out
some information, usually aliases.  It can get PATH from your
environment; I haven't bothered checking which gets precedence if path
information is in .cshrc.  It was very much written for csh, even
though it doesn't even work with it correctly.  The problem is that
which is a non-csh builtin attempting to get internal information from
the programme.  When using csh, the primary screw-ups are when you
either have a) an alias defined interactively which does not exist in
.cshrc or b) an alias mentioned in .cshrc which does not really exist in
your current shell, as in the examples above.

It does work correctly, however, for most csh users' normal
environments.  The "right way" is to have the function in the
shell.  Witness BASH's "type" builtin which gets it right for the
cases where csh fails.
================

Dave

[By the way, Robert, you might want to cut the length of your
.signature by 60%+ to avoid some flames.]
-- 
   (setq mail '("tale at cs.rpi.edu" "tale at ai.mit.edu" "tale at rpitsmts.bitnet"))