Uploaded image for project: 'Erlang/OTP'
  1. Erlang/OTP
  2. ERL-1332

Expose function for retrieving all environment variables as a proplist



    • Type: Improvement
    • Status: In Progress
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: kernel
    • Labels:


      Presently the `os` module exports two functions for retrieving all environment variables - `os:getenv/0` and `os:list_env_vars/0`.

      `os:list_env_vars/0` is not included in the documentation, so I presume it's not recommended for other applications to use it. It returns environment variables as a proplist in the format `[

      {env_var_name(), env_var_value()}


      `os:getenv/0` is included in the documentation. It returns environment variables as a list of strings in the format "VarName=Value". The strings are constructed by `os:getenv/0` in the expression that generates the return value by mapping over the return value of `os:list_env_vars/0`.


      Elixir relies on `os:getenv/0` to retrieve all environment variables it is the function that is documented and serves that purpose, but actually undoes the formatting performed by `os:getenv/0` (see https://github.com/erlang/otp/blob/master/lib/kernel/src/os.erl#L118) in its own `System.get_env/0` function (see https://github.com/elixir-lang/elixir/blob/v1.10.3/lib/elixir/lib/system.ex#L438). Elixir's `System.get_env/0` function could be greatly simplified if it used `os:list_env_vars/0` is it returns the environment variables in a proplist, which can be easily coerced to a `System.get_env/0` return type of map.

      I've not done any exact benchmarking of the two different approaches, but from my recent experience Elixir's `System.get_env/0`, which undoes the formatted performed by `os:getenv/0`, is significantly slower than just calling `os:list_env_vars/0` directly. This is especially a problem with environments with a large number of environment variables.

      Getting all environment variables returned as a key-value data structure is something I think that is widely needed.

      Possible Solutions

      One solution would be to just publicly document the `os:list_env_vars/0` function and then encourage applications to use it when they need environment var returned as a proplist.

      Another would be to change `os:getenv/0` to return the proplist from `os:list_env_vars/0` directly.




            otp_team_vm Team VM
            Stratus3D Trevor Brown
            2 Vote for this issue
            5 Start watching this issue