Make the exec command default to a login shell

[willejs]

Currently when you run aws-vault exec <profile> it runs $SHELL and puts you into a non login shell. This does not execute your shells login profile so you end up losing anything nice you have in your login profile.

Instead I think exec should default to executing a login shell. As far as I am aware all shells support -l, so this should be backwards compatible, and i don't envision any issues. This attempts to close out issue #406 too.

[mtibben]

How does this behave on Windows ?

[frezbo]

This can be easily fixed by running aws-vault exec <profile> -- bash This provides a login shell as per the system config.

[willejs]

This can be easily fixed by running aws-vault exec <profile> -- bash This provides a login shell as per the system config.

You can do this, but when you are using aws-vault exec often (when your session times out) its quite painful. Also, im not sure why you would ever want to exec into a non login shell? So i think makes sense to default to a login shell?

How does this behave on Windows ?

Good catch! I dont know to be honest, i didn't think of that! Is there anyone who can run $SHELL -l on windows? Not sure what that even does!
ahh, i am not sure about this?

[willejs]

How does this behave on Windows ?

I finally managed to test this with a vagrant box. By default it executes cmd.exe, which does not like -l. I am wondering if instead this could be set to an env var? or i could do an if windows, but I am not sure how that would work.

[mtibben]

Rather than blacklisting windows, could you whitelist shells that accept the -l flag? I believe you can run bash/zsh just fine on Windows these days and it would still be useful on windows when those shells are running

[segevfiner]

I didn't test yet, but wouldn't this cause a second execution of the shell profile under the same environment if aws-vault is executed from a login shell or a shell that has inherited the login env? This often results in doubled entries in PATH and other unwanted side effects and often caused many problems for me in other scenarios where such a situation happened.

[mtibben]

@segevfiner aws-vault by default won't execute inside it's own shell, which it determines by checking if AWS_VAULT is set.

Can you be more specific about a scenario where this might cause issues?

[segevfiner]

I'm running inside a login shell or a shell that has inherited the login shell environment as is the norm in any terminal emulator or IDE embedded terminal. I execute aws-vault inside that, which will request to start another login shell under that shell that is already a login shell or has inherited the login shell environment.

This leads to an environment that has run the login shell script twice, leading to unexpected side effects as that script expects to be called once per session (Unlike the shell rc script, e.g. bashrc. Such side effects include doubled PATH environment variables, wiping environment variables that were expected to be inherited, causing stuff like ssh-agent to be started a second time for profiles that do so, etc.

This assumes that I understood what this PR does. I didn't upgrade seeing this in the change log to avoid issues that I won't have time to work to fix ATM, at least before figuring this out here.

[mtibben]

Yes I see what you're saying @segevfiner. Hmmm maybe I'll revert this for now, aim for v6 to work out how to do this better

[mtibben]

Hey @willejs I've just been playing around with this.

I don't think a login shell is required. aws-vault already sends through the entire environment of the current shell to the new shell.

What will not come across to the new shell are local variables and functions, which may include your PS1 prompt.

If that is what you're noticing, there is a simple solution. Define any local variables and functions like the prompt functions and PS1 in the .bashrc or .zshrc which gets executed every time a new shell is started.

Does that solve your problem?

The problem with the login shell is as @segevfiner described - by running the shell profile scripts again (which are often additive) you can put your shell in a weird state. If a login shell really is required, we probably shouldn't send the entire environment through to the new shell

[mtibben]

Added docs here be6e1b6. Does this solve your problem @willejs ? (if not #406 looks like a better way forward)

[segevfiner]

It is as described by @mtibben.

Anything that should run only once should be in one of the profile script .bash_profile/.profile/.zprofile. But there is weirdness on when and which they get executed on different OS, so it takes some trial and error sometimes to figure out the behavior on the exact OS and DM, etc you are using. For example on Ubuntu by default the DM only sources .profile, but SSH with ZSH as default will source .zprofile. So I had .zprofile source .profile with appropriate compatibility.

The .bashrc/.zshrc should include anything that needs to be set on every shell, including every subshell and will be executed multiple times inheriting variables from previous executions. So this is basically anything else that isn't inherited by subshells.

Also note that many many tutorials and instructions get this wrong too.

[frezbo]

@segevfiner You sent me down a rabbit hole and made me learn something new. Thanks 👍. Based on my new learning I started using pathmunge function from /etc/profile to add in new PATH, I was getting a lot of duplicate path entries (it never caused a problem though).