3

I'm entering a namespace with nsenter -m -u -i -n -p -t $PID /bin/bash. However, printenv inside this namespace doesn't have everything I need. I'd like to send these variables in, but I'd like to avoid prefixing my bash command like KEY=VALUE KEY2=VALUE2 /bin/bash.

Is there a better way to do this?

Dane O'Connor
  • 441
  • Are the variables already set? You can pass environment around with $(set). – mikeserv Apr 16 '14 at 18:16
  • @mikeserv they're not already set unfortunately. Also, since this is an isolated namespace, I don't actually want to inherit my user's environment. I'm just looking for a more convenient way to establish the environment when entering the namespace. – Dane O'Connor Apr 16 '14 at 18:55
  • I understand how they work - I just asked my own question on them the other day. It seems to me though they're more useful the other way round - I wouldn't mind their inheritance of my environment, just they're later affecting it. You could of course use something like this: nsenter ... 5<<IN\nparam=val ; ${param=$name}=val...\nIN\n ; and the fd would be available to you in the namespace. So you could set -- $(cat <&5) or even . /dev/fd/5 at any time. You could use the shell's .dot with any file as well. – mikeserv Apr 16 '14 at 19:04
  • And for that matter: nsenter ... ENV=./env_script sh -i – mikeserv Apr 16 '14 at 19:12
  • @mikeserv can you elaborate in an answer? That last bit with ENV seems on track but I don't fully understand – Dane O'Connor Apr 16 '14 at 20:44
  • Is this environmental variables that you want to inherit from the calling shell? Perhaps this is more to do with sudo than nsenter (if that is what you are using). Maybe you want to use sudo -E or set up env_keep in /etc/sudoers. – Graeme Apr 16 '14 at 21:18
  • 1
    I don't understand: why not nsenter … env -i VAR1=VALUE1 … bash? – Gilles 'SO- stop being evil' Apr 16 '14 at 22:47
  • @Gilles that would work, but I was hoping for a more succinct way. Perhaps by leveraging an rc type file. It gets a bit out of hand when there's a bunch of variables. – Dane O'Connor Apr 17 '14 at 01:36
  • I think I've got it. I was just answering your other question actually... But it doesnt have to get out of hand - just use a positional parameter array or a function. Or a heredoc with defaults that you define occasionally as you needed declaratives like fn() ( nsenter ... ) 5<<DEFS\n${param=thing}\nDEFS\nparam=nothing fn – mikeserv Apr 17 '14 at 05:15

1 Answers1

1

I can't do much more right now, but it looks like you can use switches like --rc-file, or --profile, etc.

man bash

...

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interactive login shell, or a non-interac‐ tive shell with the --login option, it first attempts to read and execute com‐ mands from /etc/profile and ~/.profile, in that order. The --noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read.

When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. In this mode, interactive shells expand the ENV variable and commands are read and executed from the file whose name is the expanded value. No other startup files are read.

mikeserv
  • 58,310