]> git.ipfire.org Git - thirdparty/systemd.git/commit
Revert "basic/env-util: (mostly) follow POSIX for what variable names are allowed"
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fri, 23 Oct 2020 12:24:32 +0000 (14:24 +0200)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fri, 23 Oct 2020 13:07:07 +0000 (15:07 +0200)
commitff461576de63fd509713618289a698875b1a69ba
treea75cb95961cb662187edaec31e632538d79d8abd
parent451ae5a11adfdd7fa37d05543e97c966a5802924
Revert "basic/env-util: (mostly) follow POSIX for what variable names are allowed"

This reverts commit b45c068dd8fac7661a15e99e7cf699ff06010b13.

I think the idea was generally sound, but didn't take into account the
limitations of show-environment and how it is used. People expect to be able to
eval systemctl show-environment output in bash, and no escaping syntax is
defined for environment *names* (we only do escaping for *values*). We could
skip such problematic variables in 'systemctl show-environment', and only allow
them to be inherited directly. But this would be confusing and ugly.

The original motivation for this change was that various import operations
would fail. a4ccce22d9552dc74b6916cc5ec57f2a0b686b4f changed systemctl to filter
invalid variables in import-environment.
https://gitlab.gnome.org/GNOME/gnome-session/-/issues/71 does a similar change
in GNOME. So those problematic variables should not cause failures, but just
be silently ignored.

Finally, the environment block is becoming a dumping ground. In my gnome
session 'systemctl show-environment --user' includes stuff like PWD, FPATH
(from zsh), SHLVL=0 (no idea what that is). This is not directly related to
variable names (since all those are allowed under the stricter rules too), but
I think we should start pushing people away from running import-environment and
towards importing only select variables.

https://github.com/systemd/systemd/pull/17188#issuecomment-708676511
src/basic/env-util.c
src/test/test-env-util.c
src/test/test-load-fragment.c