So I'm working a script let's call it
chroot-session-builder that mounts a file-system with a separate OS, and then logs me into a chrooted shell in the other file system. It works, but I'm a jerk and I want it work great.
The relevant part is this:
mkdir -p $mount_point/root/bin && \ cp chroot-env-setup.sh $mount_point/root/bin/ && \ chroot $mount_point bash -c /root/bin/chroot-env-setup.sh && \ chroot $mount_point
So I've passed in the
chroot-env-setup.sh script. It runs and declares some stuff, the problem point being:
export HOME=/root export PATH=$PATH:/root/bin ## *** More functions... ## *** Calls to other scripts... exit 0;
Which exits the chroot context and brings me back to the running
chroot-session-builder in the context of the shell original next calling:
Bringing me into my chroot context.
Now it wasn't obvious to me until I ran some tests, and found this: How to correctly add a path to PATH?, that what's happening is that the
export statement exposes the variable to the current shell session. And the reason for my confusion was overlooking that
/root anyways. (face-palm) and thus, anything I declare, I lose when I chroot back in.
I see two potential options here:
1) I can write can
echo "export PATH:$PATH/root/bin" >> to
/root/.profile, and when
This will not require me to
source /root/.profile manually after I reenter the chroot context, because the new shell will read from /root/.profile on load.
2) The other option is if there a way to
chroot $mount_point <with a command> and then stay in the chroot context from the script, so that the
chroot-env-setup.sh script can do it's magic, and I don't have to worry about resetting anymore environmental changes or adding to files? (every file, settings adjustment I make when I enter, I have to account for and add to the clean up script before I save the file system.)