[Feature Request] Allow running bash commands in the parent environment

[rickyelopez]

Is your feature request related to a problem? Please describe. I have certain environment variables defined in my shell that specify parameters for kicking off builds on a CI server. I would like to be able to implement this functionality in LazyGit so that I can kick off builds on specific hashes, but when LazyGit runs bash commands it does not preserve the parent environment variables, so my commands can't access them.

Describe the solution you'd like I would like for there to be a way to run commands while preserving all (or even some specific) environment variables from the shell session that LazyGit is run in.

Describe alternatives you've considered I can't think of any way to get around this that doesn't involve writing the data in the env vars to a file, which I cannot do (sensitive information)

Is this doable somehow already that I'm missing? If not, is this something that is possible to add?

[mark2185]

How often do you change said variables?

Would the problem be solved if the spawned subshell parsed your rc file?

[rickyelopez]

That would solve a different issue that I have, which is that none of the aliases defined in my rc files are available when running commands from LazyGit.

Unfortunately, it doesn't resolve this one for me unless the shell session that LazyGit spawns persists for all subsequent commands. The var in question is generated after typing in a secret when running a command, so I would have to run the command and type the secret every time if LazyGit spawns a new session every time.

[mark2185]

Are you talking about custom commands or?

Could you please write an example to reproduce it?

Because I tried the following steps, with this config:

customCommands:
  - key: null
    description: 'This is a secret script!'
    command: 'bash ~/script_with_envs.sh'
    context: 'global'
    subprocess: true
    stream: true

The script's contents are: echo $SECRET_KEY

The steps I did were:

1. $> export SECRET_KEY=123
2. $> lazygit
3. Press ? and start the 'This is a secret script!' command
4. The script prints out 123

[rickyelopez]

Sorry for the delayed response! While it looks like you're probably right @mark2185, turns out there's a secondary issue which is what you mentioned earlier, my RC files aren't being sourced, which means the command I'm trying to run isn't even defined.

Also looks like I can't manually source the rc files myself (with something like source ~/.bashrc && run_command <args>) which I can't really explain, I would expect the first part to export the variables which would then be used by the second command

[mark2185]

Also looks like I can't manually source the rc files myself (with something like source ~/.bashrc && run_command <args>) which I can't really explain, I would expect the first part to export the variables which would then be used by the second command

I just tried it with this command:

    command: 'source ~/.secret_file && echo $SUPER_SECRET'

And the file contains export SUPER_SECRET=4 and it prints out 4.

Do you have something like this in your .bashrc maybe?

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

[rickyelopez]

Ha, yeah looks like I do! Let me try some other stuff. Great catch, thanks!

[rickyelopez]

Ok so yeah that totally works! Problem is, the command that I'm calling is the one that interactively gets the secret from the user. This works, except that the environment variable isn't saved, which means that the next time I try to run the command it asks for the secret again :/

[mark2185]

Ah, okay, so you really need to preserve the parent's env when launching lazygit, i.e. when launching a subshell from within lazygit.

I can't think of anything off the top of my head, but I'll mull it over :sweat_smile:

[rickyelopez]

Yeah :/

I can probably make it so that the env var already exists in the env that LazyGit is launched in to resolve, but it's going to be gross so I would love it if there was something you could add :)

[jesseduffield]

Doesn't help with persisting things but if you do '/bin/zsh -l ' it'll source your .zprofile file. This is what vscode does when you run a task on it. I had to move some env exports from zshrc so zprofile the other day to get vscode doing what I wanted

[rickyelopez]

I don't think that helps here since the secret is generated with user input when running the command, so it wouldn't exist in zprofile either. Good to know though