feat(applications): add configurable environment variables and debug logging

[devzeebo]

• Add EnvironmentVariables enum with None/Inherit/Script(PathBuf) options
• Add environment_variables config field to allow users to:
  • Inherit current process environment
  • Run custom script to generate environment variables
• Add LogLevel enum (Error/Debug) with log_level config field
• Add debug logging that outputs cwd, args, and envs before command execution
• Add shellexpand dependency for tilde expansion in script paths
• Update all Command spawn sites to use configurable environment variables

BREAKING CHANGE: None (new optional config fields with safe defaults)

[Kirottu]

I don't really understand what the point of this is, what problem does this solve that you couldn't solve with existing functionality like preprocess_exec_script?

[devzeebo]

Yes.

The preprocess_exec_script only allows you to change the script that is executed, not environment variables. Using a simple script as my preprocessor to test:

#!/bin/bash
env > ~/pre-output
export NEW_VALUE=something
env > ~/post-output

echo $(which kitty)

This should execute kitty and provide access to NEW_VALUE from within the spawned terminal. It does not. Because the preprocess script is executed in a subshell to calculate the output, and then a new subshell is used to launch the program, the new shell does not inherit any of the environment variables you exported in the preprocess script.

My original need was getting my exported PATH in my .profile, .bash_profile, or .bashrc to be accessible by the launched program. I was unable to use npm or node managed by nvm without re-sourcing a profile after launch (was really trying to launch VSCode, but kitty provided a way to easily debug env variables). I suspect this has something to do with using sh -c to launch the process, but didn't investigate that path.

Collecting the environment variables and ensuring the spawned process included them seemed like the least intrusive solution. With the change in place and the inherit value used, the spawned kitty instance has all of my user environment variables accessible. I was then able to drop the preprocess script entirely and use the regular desktop file for VSCode I was trying to launch originally, and now had PATH accessible to plugins.

If I'm missing something painfully obvious, I'd love to discuss and change to a documentation update.

[Kirottu]

You can use echo "env VAR1=value1 VAR2=value2 $2" to output a command that has overridden env vars.

[devzeebo]

Looks like prior to #304 , the preprocess script was non-functional without the terminal option, which caused my attempts to anything with that file ineffectual. Now that the output is being used, I could write a script to source the user's profile, parse the printenv into a single string, and prepend the command like you suggested.

That being resolved; is there any reason not to include a simpler, first-class way to expose environment variables to the launched program instead of needing a custom script to do so?