1

Problem

I am trying to get the edit-in-kitty command to work on my local workstation (not over SSH, yet), but it seems like the environment variables — which are usually exported while sourcing my shell's rc file — aren't carried over to the child process while executing this command. This causes a number of errors while starting the editor.

To be more specific, the editor is Vim, and examples of issues I am facing include:

  • The global variable g:colors_name is set based on the value the environment variable BASE16_THEME — which is set in my shell's rc file — and some plugin's theme cannot be applied without it.
  • Some plugin is looking for an executable inside my PATH, and fails because the PATH visible to Vim is only the system wide PATH (/usr/bin:/bin:/usr/sbin:/sbin).

I am quite certain that edit-in-kitty does receive the fully populated environment during execution, since it runs my manually installed version of Vim instead of the one that ships with the OS, which is what I expect. To me, it seems like the environment is cleared right before starting the editor.

Components:

  • kitty 0.25.2
  • zsh 5.8.1
  • Vim 9.0 (macOS version, part of MacVim)

What I tried

I set the env option explicitly inside my kitty configuration to env BASE16_THEME=default-dark, and can confirm that it carries over to Vim when I run edit-in-kitty.

Setting PATH in the same fashion, e.g. via env PATH=/custom/bin:${PATH}, would most certainly work too.

Question

The method above doesn't feel very portable to me since the environment depends heavily on my shell's configuration, which varies from system to system. Since kitty runs the shell to evaluate its environment, is there a way to instruct it to preserve this environment while launching the text editor?

Antoine Cotten
  • 113
  • 4
  • Why don't you just set the environmental variables in one of the files sourced at login rather than your shell's interactive rc file? You didn't say what login manager, so I can't tell you which file that is, but it might be, .e.g, `.zprofile` rather than `.zshrc`. You could also have one of these files itself source your rc file. – frabjous Jul 28 '22 at 17:43
  • @frabjous you're right, I could have tried the profile file instead of the rc file just to be sure. In this case though, it doesn't make a difference. kitty does run the shell with -l -i and therefore sources both, but still drops the environment before launching the child process (text editor). – Antoine Cotten Jul 28 '22 at 17:49
  • The source indicates that some sort of data transmission happens for the `edit-in-file` thing, though it's not clear to me how the editor is actually run; if kitty simply does an `exec(3)` of `vim` then the environment will come from kitty and not any of your shells. The `vim` command `:%!env` should show exactly what env `vim` got. Maybe replace the editor kitty knows about with an exec wrapper script that sets the required environment? – thrig Jul 28 '22 at 18:04
  • @thrig indeed, kitty is the parent process of Vim in this case, although I haven't looked into the details. kitty does source the shell's environment, it simply doesn't pass it to Vim. The command you suggested, which is how I inspected the environment myself, shows system wide environment variables (including the limited PATH I mentioned), along with HOME, USER, TERM, PWD, etc. and Vim and kitty specific env vars, but none of the variables set in shell configuration files (profile or rc). The exec wrapper might be the only way, although I was trying to avoid that. – Antoine Cotten Jul 28 '22 at 18:23

1 Answers1

2

The kitty page about edit-with-kitty linked to in the question mentions that it accepts the same arguments as the launch command, documented here.

It has a --copy-env option which will preserve the environmental variables of the shell from which it is launched.

frabjous
  • 8,421
  • 1
  • 32
  • 33