On 30/01/15 22:53, Elias Probst wrote: > IMHO, env variables are something we should get rid of in the long term. > It might be fine for now to provide some legacy-compatibility mechanisms > (like your not-yet-written tool), but to me environment variables are > something straight out of the dark ages.
Environment variables are specified by POSIX, also available in Windows, and one of the few easy ways for information to inherit from a parent process to a child process without the child process needing to do anything explicitly. I don't think they're going to go away, however much you might want them to - the "long tail" of (mostly TUI) programs that use them is very long indeed. I do agree that the number of them that are necessary should go down over time (and my distro of choice, Debian, has a policy of "everything we ship should be usable without manually setting magic environment variables"), but I don't think it is likely to go down to zero. > The long-term goal (also in a world where a graphical session is managed > as a systemd user-session), the information provided until now by an > environment variable should be queried dynamically by e.g. a D-Bus call > to the component responsible for providing the relevant information. Environment variables do several different things. Having a quick skim through my `env` output, here are some distinct categories: We talked about LANG a bit at the hackfest, and the consensus seemed to be that something better should happen, but nobody was sure exactly what. I don't set LC_* but if I did, they'd be in the same category. Losing DBUS_SESSION_BUS_ADDRESS was part of the point of this thread. :-) Similarly, DISPLAY, GPG_AGENT_INFO, SSH_AUTH_SOCK should be able to go away one day, when those things grow support for XDG_RUNTIME_DIR-based socket-activation. XAUTHORITY can go away eventually too, even in X11 environments, in favour of "xhost +SI:localuser:smcv" (which in fact gdm already does). DEBEMAIL, LESS, LS_COLORS, PYTHONSTARTUP, SHELL, SSH_ASKPASS, VISUAL are configuration, and could in principle be read from a dotfile instead (although good luck porting every last consumer of EDITOR, SHELL and VISUAL to your new world order - e.g. Debian has more than 37k packages). XDG_SEAT, XDG_SESSION_ID, XDG_VTNR are properties of my login-session, not my user-session or my home directory, so you can't write them to either XDG_RUNTIME_DIR or a dotfile because both would be the wrong scope. XDG_RUNTIME_DIR has to be an environment variable because you can't very well read it from the XDG_RUNTIME_DIR :-) S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel