Make it more obvious in the terminal when launching the subshell via `atmos terraform shell` about atmos HOT 7 OPEN

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

from atmos.

May I work on this issue @osterman ?

from atmos.

Possibly, could you suggest your approach?

from atmos.

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.

from atmos.

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.

from atmos.