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.

[rajhawaldar]

@osterman Apologies for the late response. Do we really need to introduce the new shell parameter to the atmos.yaml file. The code already checks for the SHELL environment variable at line /internal/exec/shell_utils.go#L173. If user sets their desired SHELL in .zshrc or .bashrc file, then our code already picks it.

I performed following steps on my local setup, and it does the job.

1. I setup /usr/bin/sh as my default shell in .bashrc file
   export SHELL="/usr/bin/sh"

2. I removed the following line from the code to not run any shell as login shell.

   atmos/internal/exec/shell_utils.go

   Line 181 in becacad

   shellCommand = shellCommand + " -l"

3. Added componentEnvList = append(componentEnvList, "PS1=atmos>") environment variable here
   

   atmos/internal/exec/shell_utils.go

   Line 163 in becacad

   Env: append(os.Environ(), componentEnvList...),

Then I just got the desired prompt as below,

@osterman, let me know your thoughts on this approach.

[osterman]

I think we can do that. I think we should implement that, and add PS1 unless it explicitly set in the atmos config.

[osterman]

This is addressed in #761