On 08/31/2017 09:26 AM, Rick Stevens wrote:
On 08/31/2017 08:34 AM, Kevin Cummings wrote:
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH
included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the
PATH?
That's the most likely issue here. The OP keeps referring to an F20
box and IIRC that predates the /bin<-->/usr/bin changeover.
To answer the question, bash has an initial PATH compiled into it.
What that PATH contains depends on how bash was built and how bash
was launched (they inherit the environment of the launching process--
interactive or not). The vast majority of systems bugger that default
path by use of the /etc/bashrc script and possibly custom scripts in
/etc/profile.d.
Interactive (login) shells are typically launched by the login process
and inherit the login process' PATH (see "man login" for details). The
additional stuff (/etc/bashrc, /etc/profile, etc.) are also invoked.
A chrooted shell gets its environment from the chroot process and would
run any normal startup scripts, but they'd be from the chrooted /etc,
not necessarily the root system's /etc.
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.
this could happen; I would think that PATH is set inside the chroot
by the shell. How does PATH get set? I see how it is modified and
have fixed my issue, provided I use a login shell.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx