On 08/31/2017 11:14 AM, Tony Nelson wrote:
On 17-08-31 12:41:09, Mike Wright wrote:
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ... chroot" and thereby eliminate the problem.
Seems to work. Note that this only changes the passed path; any pathmunge()'ing in the chroot's startup scripts still happens. I've already fixed the problem inside the chroot, but I'll set this up if I find another problematic chroot. It should be OK to look at /usr/bin twice if /bin -> /usr/bin and the command doesn't exist.
If the pathmunging is done in a "/<wherever-chroot-is>/etc/..." script or in a "~/.whatever", absolutely as that is done after the chroot spawns the shell in the chrooted environment. If you're saying it happens before the chroot, then I don't know how that'd occur.
I think the issue you've been having is that your chroot environment doesn't have the merged /bin and /usr/bin. It has separate /bin and /usr/bin directories. After the merge of /bin and /usr/bin was established, I believe bash's built-in default PATH was modified to assume this symlink was done. That's why the new bash doesn't have a separate "/bin" in its default path. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - If you can't beat your computer at chess...try kickboxing! - ----------------------------------------------------------------------