[RFC 1/1] shell: only set SHELL variable inside shell

[Felix Moessbauer]

Previously the SHELL and TERM variables were forwarded into the
environment bitbake was called in as well. However, the env setup
script was intentionally called without these variables and bitbake
internally creates the shell scripts with shebang /bin/sh. Along that,
the documentation states that both variables are only forwarded into
the kas shell plugin.

We align that by not forwarding the SHELL variable into the kas or the
build environment. Only on kas shell, we read the variable from the
calling environment and use it to start the matching shell. The TERM
variable is always forwarded, as this is used by bitbake to switch into
the interactive (tui) mode if supported by the TERM.

In kas-container we still forward the variable independent of the used
plugin to reduce the number of branches that need to be tested. We
further clarify in the documentation which variables are forwarded into
what context.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
This inconsistency was found when debugging [1]. It has been in kas
for years unnoticed and I'm not even able to find when it was
introduced to provide a fixes tag. The underlying root cause of different
shell behavior in kas and kas-container is the symlink /bin/sh points to.
In the container (and presumably all Debian systems) it points to dash.
However, this is user controlled and outside of the control of kas.

[1] https://github.com/siemens/kas/issues/159

Best regards,
Felix

docs/command-line/environment-variables.inc | 6 +++---
kas/libkas.py | 2 +-
kas/plugins/shell.py | 6 +++++-
3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/docs/command-line/environment-variables.inc b/docs/command-line/environment-variables.inc
index 875f4b343..90ecb158d 100644
--- a/docs/command-line/environment-variables.inc
+++ b/docs/command-line/environment-variables.inc
@@ -133,10 +133,10 @@ overwritten using the ``env`` section of the config file.
| | script. |
+--------------------------+--------------------------------------------------+
| ``SHELL`` | The shell to start when using the `shell` |
-| (C,K,E) | plugin. |
+| (C) | plugin. |
+--------------------------+--------------------------------------------------+
-| ``TERM`` | The terminal options used in the `shell` plugin. |
-| (C,K,E) | |
+| ``TERM`` | The terminal options used in the `shell` plugin |
+| (C,E) | and in the bitbake environment. |
+--------------------------+--------------------------------------------------+
| ``TZ`` (C) | Timezone settings. |
+--------------------------+--------------------------------------------------+
diff --git a/kas/libkas.py b/kas/libkas.py
index 89113fab8..b366cafef 100644
--- a/kas/libkas.py
+++ b/kas/libkas.py
@@ -329,7 +329,7 @@ def get_build_environ(build_system):
env.update({'BB_ENV_EXTRAWHITE': extra_white})

env_vars.extend(['SSH_AUTH_SOCK',
- 'SHELL', 'TERM',
+ 'TERM',
'GIT_PROXY_COMMAND', 'NO_PROXY'])

for env_var in env_vars:
diff --git a/kas/plugins/shell.py b/kas/plugins/shell.py
index 802f69e68..784d7fdcd 100644
--- a/kas/plugins/shell.py
+++ b/kas/plugins/shell.py
@@ -25,7 +25,9 @@
When this command is executed, kas will checkout repositories, setup the
build environment and then start a shell in the build environment. This
can be used to manually run ``bitbake`` with custom command line options
- or to execute other commands such as ``runqemu``.
+ or to execute other commands such as ``runqemu``. The ``SHELL`` environment
+ variable is inherited from the calling environment and controls which shell
+ is started.

For example, to start a shell in the build environment for the file
``kas-project.yml`` you could run::
@@ -114,6 +116,8 @@ class ShellCommand(Command):
logging.info("To start the default build, run: bitbake -c %s %s",
ctx.config.get_bitbake_task(),
' '.join(ctx.config.get_bitbake_targets()))
+ if 'SHELL' not in ctx.environ and 'SHELL' in os.environ:
+ ctx.environ['SHELL'] = os.environ['SHELL']
cmd = [ctx.environ.get('SHELL', '/bin/sh')]
if self.cmd:
cmd.append('-c')
--
2.50.0

[Jan Kiszka]

On 17.06.25 17:03, Felix Moessbauer wrote:
> Previously the SHELL and TERM variables were forwarded into the
> environment bitbake was called in as well. However, the env setup
> script was intentionally called without these variables and bitbake
> internally creates the shell scripts with shebang /bin/sh. Along that,
> the documentation states that both variables are only forwarded into
> the kas shell plugin.

What about build targets like devshell?

Jan

Siemens AG, Foundational Technologies
Linux Expert Center

[Felix Moessbauer]

On Wed, 2025-06-18 at 09:46 +0200, Jan Kiszka wrote:
> On 17.06.25 17:03, Felix Moessbauer wrote:
> > Previously the SHELL and TERM variables were forwarded into the
> > environment bitbake was called in as well. However, the env setup
> > script was intentionally called without these variables and bitbake
> > internally creates the shell scripts with shebang /bin/sh. Along
> > that,
> > the documentation states that both variables are only forwarded
> > into
> > the kas shell plugin.
>
> What about build targets like devshell?

This is independent of the kas shell and should be behave exactly as in
the build environment [1]. However, OE internally uses the SHELL
variable to control which shell to start in the devshell (undocumented
behavior) and defaults to bash [2].

In the end, this only affects the use-case of kas build --task
devshell, which I don't think people are using anyways (that might be a
bold guess...). When starting the devshell from a kas shell session,
the SHELL variable is set.

Felix

[1] https://docs.yoctoproject.org/dev-manual/development-shell.html
[2]
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/terminal.bbclass#L16

[Jan Kiszka]

On 23.06.25 04:37, Felix Moessbauer wrote:
> On Wed, 2025-06-18 at 09:46 +0200, Jan Kiszka wrote:
>> On 17.06.25 17:03, Felix Moessbauer wrote:
>>> Previously the SHELL and TERM variables were forwarded into the
>>> environment bitbake was called in as well. However, the env setup
>>> script was intentionally called without these variables and bitbake
>>> internally creates the shell scripts with shebang /bin/sh. Along
>>> that,
>>> the documentation states that both variables are only forwarded
>>> into
>>> the kas shell plugin.
>>
>> What about build targets like devshell?
>
> This is independent of the kas shell and should be behave exactly as in
> the build environment [1]. However, OE internally uses the SHELL
> variable to control which shell to start in the devshell (undocumented
> behavior) and defaults to bash [2].
>
> In the end, this only affects the use-case of kas build --task
> devshell, which I don't think people are using anyways (that might be a
> bold guess...). When starting the devshell from a kas shell session,
> the SHELL variable is set.

If SHELL is picked up by the devshell target, we should not regress.

Jan