gandalf@csli.Stanford.EDU (Juergen Wagner) (03/05/91)
There seems to be some weirdness with `which' under Ultrix 4.1.
Here is the story:
A long time ago, I wrote a "which" of my own, a program which also
told me about multiple occurrences of files, which followed symbolic
links, etc. (if given the proper options). This morning, I compiled
that program under Ultrix 4.0 (on a DecStation 3100) to see how it
worked. The result was the following (imagine, bin/which were my
personal 'which'):
foo% rehash
foo% which which
/u/gandalf/bin/which
foo% which -a which
At this point, I expected to see /u/gandalf/bin/which and /usr/ucb/which
appear on my screen. Aaarrggh! What happened was
No -a in /u/gandalf/bin/which /usr/ucb /usr/bin /bin ...
/u/gandalf/bin/which
Ok. Trying to find out what's going on, I noticed that there were
actually three "which"s around: my own, the /usr/ucb one, ...and...
a built-in which os Ultrix' csh.
Great, I thought, why not make it a built-in? I can always rename my
own "which" to "Which".
What seemed to be a little strange, however, was how the built-in
"which" behaved when I tried it on some well-known programs:
foo% which ls
No ls in .... Yes, there is /bin in my path!
foo% which nslookup
/usr/ucb/nslookup but /usr/local/bin comes first
in my path, and there *IS* an
nslookup, too.
Does anybody have any comments on this? I am not sure whether the
behavior of "which" described above is a bug or a feature... besides,
it is not documented as a built-in.
--Juergen Wagner (gandalf@csli.stanford.edu)
PS: Please, copy my e-mail address on any followups since I do not
read this newsgroup regularily.yeates@motcid.UUCP (Tony J Yeates) (03/07/91)
gandalf@csli.Stanford.EDU (Juergen Wagner) writes: >What seemed to be a little strange, however, was how the built-in >"which" behaved when I tried it on some well-known programs: The which in tcsh & csh is faulty, causing much confusion and wasted time. The tcsh people are aware of this & it sounds like they will fix it in a future release. I think tcsh currently uses the original csh code - so bugs, as well as features, were inherited. - Std. disclaimer
per@erix.ericsson.se (Per Hedeland) (03/10/91)
In article <5946@iron6.UUCP> yeates@motcid.UUCP (Tony J Yeates) writes: >The which in tcsh & csh is faulty, causing much confusion and wasted time. >The tcsh people are aware of this & it sounds like they will fix it in a >future release. Perhaps you could be a bit more specific about this - the only case where I know the built-in 'which' in the current version (5.20.2) of tcsh does the wrong thing is with "which ''builtin-or-alias" - but only Chris Torek does such things:-). Older versions of tcsh didn't handle "which 'builtin-or-alias'" or "which \builtin-or-alias" correctly - not so anymore. >I think tcsh currently uses the original csh code - so bugs, as well >as features, were inherited. This is pure nonsense, as the "original csh code" as far as tcsh is concerned - i.e. that of 4.2 or 4.3 BSD csh - doesn't have a builtin 'which'! According to the tcsh manual, the builtin 'which' was added by Rayan Zachariassen in 1984 - I don't really know if Ultrix had seen the light of day at that time, in any case I'm confident that he didn't get the code from Ultrix csh. As for Ultrix csh, I don't have access to 4.1, but in 4.0, 'which' is indeed builtin, while not documented as such. And while I wouldn't be surprised if yet another of Ultrix' "improvements" turned out to not be one, I can't reproduce the original poster's problems - for some incomprehensible reason, it doesn't know about csh builtins, but at least it pays attention to current $path and aliases, which the non-builtin 'which' in 4.2/3 BSD does not (for more-or-less obvious reasons). --Per Hedeland per@erix.ericsson.se