Why? Note that several of them (HOME, SSH_AUTH_SOCK, DISPLAY) are likely to be actively wrong, and others (TERM) imply dependencies that might not exist in the container.
I’m pretty sure just running env(1) will spit out a list of environment variables in a format that’s usable.
I have automation scripts that work off of 20-30 environmental settings that are set before the test is run. i was just hoping for a quick link between host and container. I had not considered that this could improperly set some env variables.
I was able to get all the env variables desired with the env command and use the result to pass env variables to the container (not exactly a quick link but it will do)