Search $PATH failure?
Bart Kus
me at bartk.us
Fri Dec 2 04:45:48 UTC 2011
On 12/1/2011 6:37 PM, Harald Becker wrote:
> IMHO as your question contains massive novice failures I suggest
> reading a book or other sources of information about Unix/Posix sytem
> basics (before asking in a specialized mailing list like Busybox). --
> Harald
Ok, let's try this again, this time when a bit less sleep deprived:
jo tmp # (mkdir ram && cd ram && gunzip < /boot/initramfs | cpio -idm)
37624 blocks
jo tmp # PATH= /usr/bin/chroot ram bin/busybox ash
/ # PATH=/bin:/usr/bin
/ # export PATH
/ # echo $PATH
/bin:/usr/bin
/ # uname
ash: uname: not found
/ # ls -l /bin/uname /bin/busybox
-rwxr-xr-x 1 0 0 2087264 Dec 1 09:03 /bin/busybox
lrwxrwxrwx 1 0 0 7 Dec 2 04:14 /bin/uname ->
busybox
/ #
I don't think the device node failures have anything to do with $PATH
processing, but they've been addressed in this example.
It's sufficient to just set PATH=/bin without exporting since I don't
care if the uname process environment has a PATH variable. In this
example $PATH is only set so ash can use it to find uname and execute
it. However I've exported it as per your request.
Now, to flex the code path where $PATH is set to a sufficient value
prior to busybox/ash execution, here's the last example:
jo tmp # PATH=/bin:/usr/bin /usr/bin/chroot ram bin/busybox ash
/ # echo $PATH
/bin:/usr/bin
/ # uname
ash: uname: not found
/ #
You agree this is incorrect behavior, yes?
PS: It looks like if I substitute the busybox that emerge generates vs.
the one that genkernel creates this problem no longer manifests. I'll
need a bit more time to figure out where genkernel might be going wrong.
--Bart
More information about the busybox
mailing list