Could we please not re-open this pointer to function returning pointer
to indeterminate array of cans of worms?  The simple answer is put /bin
before /usr/bin.

The answer to 'why not compile dynamic versions' is 'why duplicate them'?
Show of hands:  How many people find that having an extra directory or two
in their path costs them that much time?  How many people find that it would
make sense to have shared equivalents of static binaries?

I don't think it would do a whole lot of good -- if you're worried about
saving time, what about the time gained by having ld.so do all the loading
work?  Think, man, that's a USERland process which would have to dynaload
all the function stuff.  On programs with larger static load overhead, maybe
it makes sense, but the binaries in /bin and /sbin are typically fairly
small...

in /bin, the "gross offenders" (larger than 150k, which is still peanuts,
largest 360k, in size order):
    sh, ksh, csh, rcmd, rcp, ps, rm and pax.

(rm is larger than pax?!?  sh is larger than either csh or ksh??!?)

in /sbin we have (in size order, largest 336kB):
	fsdb, restore/rrestore, dump/rdump, routed, dhclient, fsck_ffs,
	mount_portal, fsck_ext2fs, mount, ifconfig, mount_ados,
	route, mount_msdos, init, ipf, ping, shutdown, mount_filecore
	halt/reboot, umount, savecore and mount_nfs.

This is NetBSD/SPARC.  Your mileage may vary.  On i386 i suspect very
few of the above binaries exceed 150kB.

I don't think the gain of duplication and eliminating two directories
from your search path (given hashing) will offset the loss of dynamic
load time and disk space consumed.


				--*greywolf;
--
"I am Buzz Lightyear, ->SPACE RANGER<-"
"You are a TOY!  T-O-Y: TOY!"