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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- If you can't beat your computer at chess...try kickboxing! -
----------------------------------------------------------------------