toolbox/test
Debarshi Ray 1ce59a6a2d cmd/run: Ensure that 'run' has the same container environment as 'enter'
Currently, commands invoked using 'toolbox run' have a different
environment than the interactive environment offered by 'toolbox enter'.
This is because 'toolbox run' was invoking the commands using something
like this:
  $ bash -c 'exec "$@"' bash [COMMAND]

... whereas, 'toolbox enter' was using something like this:
  $ bash -c 'exec "$@"' bash bash --login

In the first case, the helper Bash shell is a non-interactive non-login
shell.  This means that it doesn't read any of the usual start-up files,
and, hence, it doesn't pick up anything that's specified in them.  It
runs with the default environment variables set up by Podman and the
Toolbx image, plus the environment variables set by Toolbx itself.

In the second case, even though the helper Bash shell is still the same
as the first, it eventually invokes a login shell, which runs the usual
set of start-up files and picks up everything that's specified in them.

Therefore, to ensure parity, 'toolbox run' should always have a login
shell in the call chain inside the Toolbx container.

The easiest option is to always use a helper shell that's a login shell
with 'toolbox run', but not 'toolbox enter' so as to avoid reading the
same start-up files twice, due to two login shells in the call chain.
It will still end up reading the same start-up files twice, if someone
tried to invoke a login shell through 'toolbox run', which is fine.
It's very difficult to be sure that the user is invoking a login shell
through 'toolbox run', and it's not what most users will be doing.

https://github.com/containers/toolbox/issues/1076
2022-10-25 16:56:20 +02:00
..
system cmd/run: Ensure that 'run' has the same container environment as 'enter' 2022-10-25 16:56:20 +02:00