On Lu, 29 iun 20, 11:52:45, Greg Wooledge wrote:
> On Mon, Jun 29, 2020 at 05:19:49PM +0200, l0f4r0@tuta.io wrote:
> > I'm not sure to understand what you want to achieve exactly, but aren't you
> > supposed to use pam_env for setting/unsetting your environment variables?
>
> We can only speculate about the OP's actual goal, but I'll tell you
> what *I* was hoping to achieve when I looked into this stuff a while
> back.
>
> The holy grail, for me, would have been a way to specify environment
> variables that are applied to all user logins, whether by console login,
> or ssh, or Display Manager, independent of the user's login shell.
Been there...
> And those variables must include a way to reference existing shell
> variables like $HOME, so that one can (for example) set MAIL=$HOME/Maildir/
> somewhere and have it actually *work*.
... or XDG_CONFIG_HOME, XDG_DATA_HOME.
> pam_env gives us the /etc/environment file which is potentially useful,
> as it does in fact support many of the features I was looking for. But
> you cannot use reference to other shell variables there. If you put
> MAIL=$HOME/Maildir/ in /etc/environment and login, you will have the
> literal characters $ H O M E in the resulting variable.
>
> Even more subtly, it turns out that at the time this particular PAM
> module runs, the HOME variable isn't even *set* yet. So, even if you
> used some module that can use existing variables, it wouldn't help
> for this. (Yes, I went down that pathway too.)
>
> When I investigated environment.d, I was hoping that it could replace
> pam_env and actually support the setting of environment variables in
> user login sessions, including references to basic common variables like
> HOME and LOGNAME. The man page *looks* promising, even supporting some
> of the fancier shell expansions like ${VAR:-default}.
Yep.
> It turns out that this environment.d thing is only used for "services",
> not user logins. Who cares about "services"? If you need a variable to
> be defined for a service to run, you'll set it in the service's unit file,
> or you'll have a config file full of all the variables this service needs.
> You don't need to use environment.d for that. You don't *want* to use
> environment.d for that. Using environment.d would set the same variables
> in every service. Who does that? What kind of setup would involve such
> a thing?
You might find some use case for that if you try to move everything
under XDG_CONFIG_HOME and XDG_DATA_HOME and/or don't want to override
user .service units provided by the distro (in /usr/lib).
> So, in the end, the only way to add nontrivial, real-life variables to
> all user logins is to configure *every* possible login vector and shell
> individually. There has been less than zero progress on this front in
> 30 years.
So far I've settled to the snippet below in *both* ~/.profile and
~/.xsessionrc (inspired by a similar snippet in /etc/profile):
if [ -d "$HOME"/.config/environment.d ]; then
for i in "$HOME"/.config/environment.d/*.sh; do
if [ -r "$i" ]; then
set -a
. "$i"
set +a
fi
done
fi
(improvements welcome)
Where the same variable needs to be set also for 'systemd --user' I just
symlink the .sh file to a .config (or vice-versa, whatever).
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature