Hi, > The child process's environment should be manipulated the same way > by lxc-attach as it would be by lxc-start or lxc-execute.
Just a short question: don't you at least want to set PATH to some sane default such as /usr/local/bin:/usr/bin:/bin or so? For example, my getent logic introduced in 0.9rc1 will probably fail if you do this, since it tries to look up the binary using $PATH. Also, "lxc-attach -n foo -- ls /bin" seems to be a very reasonable use case and it'd be weird if that failed due to a missing PATH environment variable when lxc-attach does execvp. Additionally, if you don't enter the mount namespace (lxc-attach -s NETWORK for example) and just want to run a local program, you probably want to keep the environment, because that program is not really completely inside the container anyway. Use case: lxc-attach -s NETWORK -n foo -- ip -4 addr add blub (Using the host's ip utility) I think cleaning up the environment is generally a good idea, but the different use cases for lxc-attach have to be thought through a bit better, simply clearing the environment and setting container=lxc will only work properly if you spawn a shell that reads /etc/profile or similar in the container. (I apologize if this mail comes a cross as a bit negative, I don't mean it to be, I like the general idea, but what you added breaks a few things I'm doing with lxc-attach.) -- Christian ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
