When genie preserves Windows environment variables and working directory

(Definitive answer to questions about when genie copies environment variables and sets the current dir.)

genie implements systemd as a pluggable authentication module (PAM) for wsl. To do this, genie creates a container within WSL in which systemd(1) runs as pid 1, init. As such, it expects

1. itself to set up the system environment itself, and
2. for the PAM to set up user environments when a user session is created (i.e., when using genie -s or genie -c).

As such, unlike using WSL without genie, a complete user session with its own environment is created (rather than simply spawning a shell under Microsoft's pseudo-init).

This means that by default, sessions inside the bottle have the environment created for them by systemd and PAM, followed by the user's own shell login/profile scripts. This is what should happen since, unlike WSL without genie, you are actually logging in to the genie container using the relevant systemd facilities. genie should not simply clone the outside environment into the bottle, as this overwrites everything set up by systemd, and as such doing so would break the very services that you presumably invoked systemd to be able to use in the first place.

Thus:

Path

Since 1.30, if the clone-path setting in /etc/genie.ini is set to true, genie merges the outside-bottle $PATH, including the Windows $PATH, with the Linux default path to create the path for your user session. Otherwise, the outer $PATH is not merged.

See also: "Open a linux shell" and genie.

Other Environment Variables

By default, only a very limited set of environmental variables (those needed to make interop work) are copied from outside to inside the bottle, in order to preserve the parts of the environment created by systemd(1) and systemd services, both system and user.

If you need to copy other environment variables, you can add additional variables to the clone-env setting in the /etc/genie.ini file. Note, however, that trying to use this mechanism to transfer $PATH over rather than using the clone-path mechanism will almost definitely break things.

Cwd

genie -s does not preserve cwd; obeying login semantics, it runs the user's shell in the user's home directory.

genie -c does preserve cwd; the command specified runs in the current working directory, so, for example, running wsl genie -c pwd in the C:\Working directory under Windows should return /mnt/c/Working.

This will not be changing.