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