Hi Mitchell I have been looking at the man page of pam_env.conf(5) / environment(5). I've assumed pam_env to traditionally be the thing that has always been loading that file, and as such, it's documentation to be authoritative for the format of said file.
The aforementioned man page states: > The /etc/environment file specifies the environment variables to be set. > The file must consist of simple NAME=VALUE pairs on separate lines. The > pam_env(8) module will read the file after the pam_env.conf file. If we assume this to be the entire specification for the format of said file, then that doesn't include comments. That said, in retrospect, it seams that may not have been the case after all. The pam_env(8) man page for example mentions that a variable can be prefixed with "export " for bash compatibility and that it won't do anything. I wouldn't be surprised if it actually did support comments and it's just not documented. I also noticed that it removes " quotes from the start and end of a value. I'm not sure what other processing it does. By the way, pam_env certainly will not expand variables the way the so-called freedesktop "standard" (or rather, systemd documentation, really), does. I don't use systemd myself, but this would certainly also affect systemd systems in some contexts / environments, assuming they also use pam_env, which most systems tend to do, as far as I know. On the other hand, based on what that document says, systemd may not handle " quotes, unlike pam_env does. So if /etc/environment is to be a subset of what bash and pam_env allow, I should put values containing a space in quotes. If /etc/environment is to be compatible with systemd and pam_env, I mustn't put such a value in quotes. And if /etc/environment is to be compatible with systemd, pam_env and bash sourcing, that means I can't put spaces and many other things in that file. I'm not sure what the best way to resolve this format mismatch is. If the file is to be bash source-able, then my change should be reverted. That'd mean it can't contain spaces and some other things. (Unless systemd adds support for quotes there, that is), and that should then probably be documented somewhere. If it is not to be bash source-able, then the parsing logic of my previous change should probably be extended to allow comments. Regards, Daniel Abrecht
