The current which is a hack (look a the source).
It's main problem is that it returns directories
as if these are executable (because the execute mode bit
is set).  This gives problems in some cases and is
inconsistent with the documentation.

I am willing to rewrite `which', let me know where
to send the new tar.gz and rpm etc.

--
From current discussion with config.guess author:

Ben Elliston (bje) wrote:
| > From: Carlo Wood <carlo.nl>
| > Message-Id: <199903091509.QAA03972>
| > Subject: binutils bug: config.guess
|
| > when trying to compile binutils-2.9.1.0.22b, I ran
| > into a problem with config.guess.
| > I have "." in my PATH, and it seems that makes
| > config.guess fail to execute `ld'. It tries to execute
| > the directory ld/ in binutils.
| > I know I shouldn't have a "." in my path before
| > /usr/bin, but I am sure I am not the only one that
| > has it any way :).
|
| This is quite a specific case that causes this to fail.
| Since it only occurs when there is a subdirectory named
| `ld' (as there is in binutils) and then only when you
| have `.' in front of the path to your ld program, I
| am inclined to suggest a binutils-only modification to
| config.guess that just warns:
|
|       if test -d `which ld`
|         echo "Error: cannot invoke ld"
|       fi

It is actually a bug in `which' anyway.
The documentation of `which' claims:

       Which  takes a series of program names, and prints
       out the full pathname of the program that the shell
       would call to execute it. It does this by simulating
       the shells searching of the $PATH environment
       variable.

But this is not correct in this case:

>mkdir ld
>which ld
./ld
>ld -V
GNU ld version 2.9.1 (with BFD 2.9.1.0.15)
  Supported emulations:
   elf_i386
   i386linux


`which' should skip anything that is not executable
and continue the search.  If fails to do that for
directories (maybe it only looks at the mode?).

I am going to write a new which that fixes that :/

--
 Carlo Wood  <carlo.nl>