[Suggestion] Update XDG_CONFIG_HOME when created with --home

[bsvh]

Is your feature request related to a problem? Please describe.
I created a distrobox with a separate home for working on some software in a clean environment. I noticed that the software was creating config files in my $XDG_CONFIG_HOME, which is set to $HOME/.config. This was unexpected for me, as setting --home was specifically so that user configuration files were not loaded.

Describe the solution you'd like
Unset $XDG_CONFIG_HOME, $XDG_CACHE_HOME, $XDG_DATA_HOME, and $XDG_DATA_DIRS.

Describe alternatives you've considered
You could also set $XDG_ to the standard locations in the container's home, but I think that is making too many assumptions and could be handled by --env. You could also leave it as is and let the user update --env, but I think if someone is using --home they don't want to keep the $XDG_ vars set.

[orowith2os]

It's probably better to set the XDG base dir variables inside of the custom home, and not unset them; we shouldn't be promoting having the variables unset. The user can override them if desired.

[luc14n0]

Ignoring XDG_* variables inherited from the user's shell configs when using --home might be a better term than unset, but in the end it's basically the same thing: not having them on the container's environment. Of course that re-setting them based on the value passed to --home is another option too.

After a quick assessment, even adding options to keep them (but reset them based on --home's value) and to get rid of them shouldn't be hard.

[luc14n0]

By the way, a quick solution one could use would to go to config file where they are setting the XDG_CONFIG_HOME variable and add some logic so to make a given Distrobox container to either use a different value or just not set the variable at all, something like:

1. First the logic in the RC file of your shell:

if [ "$DBX_CONTAINER" = "my-container" ]; then
    XDG_CONFIG_HOME=/same/location/used/with/--home
else
    XDG_CONFIG_HOME=/path/to/location/of/choice/on/the/host/system
fi

This was the different values strategy.

if [ "$DBX_CONTAINER" != "my-container" ]; then
    XDG_CONFIG_HOME=/path/to/location/of/choice/on/the/host/system
fi

And this one, selective setting strategy. Only setting XDG_CONFIG_HOME on environments that don't have DBX_CONTAINER=my-container

3. And now all we need to do is to finally set the variable when launching the Distrobox container.

$ distrobox enter --additional-flags '--env DBX_CONTAINER=my-container' --name my-container-name

The basic idea is to set a specific variable in the container environment that can be checked in the shell config file(s). I personally use this kind of logic to selective choose what the config files do based on where the shell is being opened, whether it's on the host or on a (specific) Distrobox container.

[misobarisic]

Distrobox already adds $CONTAINER_ID env variable. You can use it instead of setting something similar manually.

[luc14n0]

Yes, for this particular case using CONTAINER_ID should suffice.

[krakjn]

@luc14n0
Interesting, so the idea is for the user's interactive shell files to pick up on the fact they are in container and thus change $PATH and other environment vars.

I have been messing around with --init-hooks and --additional-flags on distrobox-create to change shells and set the PATH correctly. The issues are:

1. Reading through this I see the profile is capturing both bash and zsh, but unfortunately I am on fish.
2. I notice the default shell on alpine linux is bash what if I want to stay on /bin/ash?
3. Love the deep binding of host and container, this project is incredible. But is there a way to isolate shells? I have separate programs on separate paths and if I change shells it doesn't persist. If I keep shells PATH works but it's polluted with host PATH.

I am running alpinelinux container on a nixos host. I would love a --shell or --path argument to prepend/overwrite/append on these critical env vars.

I have tried distrobox assemble create with a distrobox.ini to workaround this but I get one or the other, never both.

Summary: sanitized PATH and different shell than host would be huge. I am willing to contribute here.