Impossible to set environment variables without clearing environment

[9999years]

With setEnvInherit, a process can be executed with the environment variables inherited from the parent:

ghci> runProcess_ $ proc "sh" ["-c", "env"]
SHELL=/opt/homebrew/bin/fish
ITERM_PROFILE=Default
COLORTERM=truecolor
XPC_FLAGS=0x0
TERM_PROGRAM_VERSION=3.4
...

setEnv can be used to set environment variables, but doing so prevents the subprocess from inheriting any environment variables from its parent:

ghci> runProcess_ $ setEnv [("a", "b")] $ proc "sh" ["-c", "env"]
sh: line 1: env: command not found
*** Exception: Received ExitFailure 127 when running
Raw command: sh -c env

I'd like to (e.g.) run a program with environment variables inherited but with some changes.

[tomjaguarpaw]

How about getEnvironment followed by making your changes followed by setEnv?

[9999years]

@tomjaguarpaw That sounds like a decent workaround, but it's challenging to compose without fetching the environment multiple times. getEnvironment would also mean constructing the ProcessConfig has to happen within IO.

I'd really like something closer to the Rust Command API:

• env(k, v) appends an environment variable to the subprocess
• envs([(k1, v1), (k2, v2), ...]) appends multiple environment variables
• env_clear() prevents the subprocess from inheriting variables, equivalent to setEnv []
• env_remove(k) removes an environment variable from the subprocess

This supports the standard case nicely (inheriting the parent environment but adding or modifying a few variables), composes well (env, envs, and env_remove all have sensible behavior when called multiple times), and gives users an opt-in to not inherit the environment with env_clear.

Maybe we could have:

• addEnv :: String -> String -> ProcessConfig i o e -> ProcessConfig i o e
• addEnvs :: [(String, String)] -> ProcessConfig i o e -> ProcessConfig i o e
• clearEnv :: ProcessConfig i o e -> ProcessConfig i o e
  Equivalent to setEnv [] today
• removeEnv :: String -> ProcessConfig i o e -> ProcessConfig i o e

And we could add a note on setEnv to indicate that it might not do what users expect.

[tomjaguarpaw]

How about just

modifyEnv ::
  ([(String, String)] -> [(String, String)]) ->
  ProcessConfig i o e ->
  ProcessConfig i o e

in terms of which all others can easily be done? For example

• addEnv k v = modifyEnv ((k, v) :)
• addEnvs envs = modifyEnv (envs ++)
• clearEnv = modifyEnv (const [])
• removeEnv: not sure but something like Data.List.deleteBy. I don't know if we have something quite right in base

Is having separately named functions for each of these things important to you? If so then perhaps as an alternative we could have

• add k v = ((k, v) :)
• adds = (++)
• clear = const []
• remove = <something>

and then use

modifyEnv (add k v), modifyEnv (adds envs), mofifyEnv clear, modifyEnv (remove k).

[9999years]

I think each of these functions are important enough to warrant their own bindings, yes.

I also suspect that a generic modifyEnv function will see very limited use.

I also think that having the changes listed explicitly (e.g. "remove these variables, set these variables, inherit others") will make it easier to construct informative and useful error messages.

[tomjaguarpaw]

OK, I'll summarise my understanding so far.

---

• Task: run process with a modification of the current environment variables
• Difficulty: current interface only allows construction of a ProcessConfig that uses
  1. the exact same current environment (setEnvInherit) or a specific environment, or
  2. an environment independent of the current (setEnv)

---

• Workaround: get the current environment using System.Environment.getEnv, modify it, and use setEnv
• Difficulty: requires reaching in to another unrelated module, requires creating a ProcessConfig in IO

---

• Proposal 1: Add

  setModifyEnv ::
    ([(String, String)] -> [(String, String)]) ->
    ProcessConfig i o e ->
    ProcessConfig i o e

  (slightly different name from the suggestion above because it sets the environment modifier, it doesn't modify the environment).

  One way to do this would be to modify pcEnv from Maybe [(String, String)] to ([(String, String)] -> [(String, String)]). However, if we are inheriting the environment, or setting it to something independent of the current environment then a more sophisticated type could avoid unnecessary reading of the current environment, for example

  data Env = Inherit | Set [(String, String)] |Modify ([(String, String) -> (String, String)])

---

• Proposal 2: Augment Proposal 1by adding helper functions that add one var, many vars, clear the env, or remove an entry.

---

@9999years, does this match your understanding?