Busybox symlinks into /usr/bin

[AmatCoder]

I'm wondering:
Is there any reason to put some busybox symlinks into /usr/bin and others into /bin?
Should not they all be in /bin?

Problem arise when I load coreutils.tcz, xz.tcz or similar... They do not replace some busybox equivalents.

[gerald_clark]

If you want to find programs in /usr/local/bin and /usr/local/sbin first, change your PATH.

[AmatCoder]

Consider following sequence:

Code: [Select]

tc@box:~$ echo $PATH
/home/tc/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/apps/bin:/etc/sysconfig/tcedir/ondemand

tc@box:~$ tce-load -i coreutils
libattr.tcz: OK
libcap.tcz: OK
gmp.tcz: OK
attr.tcz: OK
acl.tcz: OK
coreutils.tcz: OK

tc@box:~$ which install
/usr/local/bin/install

tc@box:~$ install --help
BusyBox v1.19.4 (2012-03-09 02:27:21 UTC) multi-call binary.

Usage: install [-cdDsp] [-o USER] [-g GRP] [-m MODE] [SOURCE]... DEST
[...]It's wrong.

But if I open another terminal it is correct:

Code: [Select]

tc@box:~$ install --help
Usage: install [OPTION]... [-T] SOURCE DEST
  or:  install [OPTION]... SOURCE... DIRECTORY
  or:  install [OPTION]... -t DIRECTORY SOURCE...
  or:  install [OPTION]... -d DIRECTORY...

This install program copies files (often just compiled) into destination
locations you choose.  If you want to download and install a ready-to-use
package on a GNU/Linux system, you should instead be using a package manager
like yum(1) or apt-get(1).
[...]

tc@box:~$ which install
/usr/local/bin/install
and this only happens with busybox symlinks into /usr/bin .

Example in first terminal with 'cp' (busybox symlink is into /bin):

Code: [Select]

tc@box:~$ cp --help
[...]
Report cp bugs to bug-coreutils@gnu.org
GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
General help using GNU software: <http://www.gnu.org/gethelp/>
Report cp translation bugs to <http://translationproject.org/team/>
For complete documentation, run: info coreutils 'cp invocationIt's correct.

[gerald_clark]

hash -r

[Rich]

Hi gerald_clark
Thanks for that concise yet terse answer, I was not aware of this. For those looking for an explanation of what
this means, this seems to cover it pretty nicely:
http://crashingdaily.wordpress.com/2008/04/21/hashing-the-executables-a-look-at-hash-and-type/

[AmatCoder]

Yes, that works but it can be avoided if all busybox symlinks were in /bin (mostly are...)

User expects to use GNU version of coreutils right away of loading coreutils extension without to reset the hash table...

[gerald_clark]

It is not the location of the symlink, but rather that you had previously run the command prior to loading coreutils.

[Rich]

Hi AmatCoder
The same thing would still have happened even if the busybox link were in /bin.

[curaga]

Yes, it wouldn't matter if they were only in /bin, the same would happen. As for why some are in /usr/bin, it's the default path in bb make install, usually because some packages expect (hardcode) them in that dir.

[roberts]

Wouldn't it be as simple as adding "hash -r"  to the coreutils startup script?

[curaga]

No, that would do it in a different shell session.

[AmatCoder]

First, thanks to all for replies.

Second, yes, I was wrong with 'precedence-path' assumption... Some tests I made confused me.

Wouldn't it be as simple as adding "hash -r"  to the coreutils startup script?

No, that would do it in a different shell session.

With bash is possible override this behaviour in order that all shell sessions do not use hash table (with 'set +h'  into ./bashrc or editing $SHELLOPTS environment variable) but with ash I guess there are no way.

[curaga]

Doing that costs performance (requires a path lookup for every command), moreso on slower systems, so I'm against disabling the hash table by default.