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@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - If you can't beat your computer at chess...try kickboxing! - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
