Make it more obvious in the terminal when launching the subshell via atmos terraform shell

[nitrocode]

Describe the Feature

Sometimes we're in the subshell and forget that the subshell is specific to a stack and then try to plan/apply a different stack which leads to errors.

If the PS1 or something can be modified to show that atmos is in the atmos terraform shell mode, it would be very helpful.

Expected Behavior

For example, if you're in the shell stack ue1-eks, then atmos should throw a warning if you're trying to run atmos within the shell against another stack.

Use Case

Forgetting that you're in a subshell

Describe Ideal Solution

Maybe a warning or a PS1 change to show you're in a subshell

Alternatives Considered

No response

Additional Context

No response

[osterman]

Yes, I could see that the PS1 maybe should be overridden to something plain like (atmos) ue1-eks > so it's clear you're in the shell and for which particular stack. We could then maybe disable this behavior by passing --override-ps1=false

[rajhawaldar]

May I work on this issue @osterman ?

[osterman]

Possibly, could you suggest your approach?

[rajhawaldar]

I thought of introducing the PS1 environment variable in the componentEnvList at internal/exec/shell_utils.go#L163. I tried this on the forked setup locally but the PS1 value is not getting override :( . So for now, I don't have any alternate approach.

[osterman]

Good news, bad news. @rajhawaldar @nitrocode

Bad News

Bad news is, I think little can be done here, since we're just invoking a "login" (-l) shell based on SHELL. The login shell will always overwrite the environment. There's no general solution that will work, other than the developer modifying their own .zshrc or .bashrc file with a custom prompt.

Alternatively, we could make shell a parameter in the atmos.yaml, and if set, use that over the SHELL env. In that case, the default shell can be changed to not include -l, which then will not load the RC files.

Good News

The line @rajhawaldar shows that it already passes the component's deep merged environment. The prompt is controlled by PS1 (for bash).

Just set the following in the Stack configuration and it should work.

env:
  ATMOS_PS1: "atmos>"
  # This works, but gets overridden by the shell's rc file.
  # PS1: "atmos>"

Then in your local rc file, check for that variable and set the prompt to it. It's not the ideal solution, and there's nothing about calling an interactive.

If @rajhawaldar wants to add the shell parameter to the atmos.yaml, and it solves the PS1, that would be appreciated.

[kevcube]

@osterman @rajhawaldar maybe something slightly higher-level, like finding some common way to edit PS1 through shell tools that many humans use, like starship.rs or oh-my-zsh etc.