Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: AmatCoder on April 27, 2012, 05:14:28 PM
-
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.
-
If you want to find programs in /usr/local/bin and /usr/local/sbin first, change your PATH.
-
Consider following sequence:
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:
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):
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 invocation
It's correct.
-
hash -r
-
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/
-
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...
-
It is not the location of the symlink, but rather that you had previously run the command prior to loading coreutils.
-
Hi AmatCoder
The same thing would still have happened even if the busybox link were in /bin.
-
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.
-
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.
-
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. :'(
-
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.