You are not logged in.
Pages: 1
Topic closed
Hello
For my personal application files (split up according to the XDG Base Directory Specification), I took the structure of the Linux Filesystem Hierarchy (FHS) as a role model, and I have recreated the content of /usr/local inside my ~/.local (+ the equivalent of /var)¹. The structure looks as follows:
~/.local/bin ← PATH
~/.local/etc ← XDG_CONFIG_HOME
~/.local/include
~/.local/lib ← LD_LIBRARY_PATH
~/.local/opt
~/.local/share ← XDG_DATA_DIRS
~/.local/srv
~/.local/var/cache ← XDG_CACHE_HOME
~/.local/var/lib ← XDG_DATA_HOME
~/.local/var/log ← XDG_LOG_HOME (not standard, but I set and use it anyway)
I use ~/.pam_environment to set my XDG basedir environment variables rather than the shell initialisation files, so that my systemd user services use the correct values.
Today I wanted add a definition for XDG_DATA_DIRS; the documentation says this:
$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.
If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.
I would like to prepend ~/.local/share to XDG_DATA_DIRS¹. In shell, this is a no-brainer:
XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"
export XDG_DATA_DIRS="$HOME/.local/share:$XDG_DATA_DIRS"
And it would look something like this:
/home/ayekat/.local/share:/usr/local/share:/usr/share
Now, of course I could simply put this in my ~/.pam_environment:
XDG_DATA_DIRS DEFAULT="@{HOME}/.local/share:/usr/local/share:/usr/share"
But this "hardcodes" the assumption that XDG_DATA_DIRS is empty and thus to be treated as `/usr/local/share:/usr/share`. In most cases, XDG_DATA_DIRS is indeed empty, so it is usually OK. But in case the system administrator sets a custom value, my assumptions will be wrong.
Reading the examples for DEFAULT and OVERRIDE in the pam_env.conf man page, I (admittedly randomly) tried this:
XDG_DATA_DIRS DEFAULT="/usr/local/share:/usr/share" OVERRIDE="${XDG_DATA_DIRS}"
XDG_DATA_DIRS DEFAULT="@{HOME}/.local/share:${XDG_DATA_DIRS}
But it appears that the lines are not processed sequentially, but in a "VHDL-constant-signal-propagation"-line manner², and it seems to cycle 3 times before "giving up", and I end up with this:
$ echo $XDG_DATA_DIRS
/home/ayekat/.local/share:/home/ayekat/.local/share:/home/ayekat/.local/share:/usr/local/share:/usr/share
It is technically not wrong, but I would rather not have the same path appear three times in there.
My Google/DDG-Fu is a little weak on this one. I haven't found any way to achieve this "expand a variable that might be set or not" in .pam_environment. Does anyone have any pointers to where I could find more information on this?
Thanks in advance!
--edit 2017-06-12T23:02 UTC: add final goal (FHS in ~/.local)
--edit 2021-12-06 I no longer try to expand XDG_DATA_DIRS in ~/.pam_environment, and ~/.pam_environment is now deprecated anyway, so the issue presented here is no longer relevant. Marking as "solved".
____
¹ See https://github.com/ayekat/dotfiles/blob … .md#xdgfhs if you're interested in the details.
² I don't know how this is called.
Last edited by ayekat (2021-12-06 09:32:40)
Offline
idkaa, but you could try bringing a second variable like
MY_DATA_DIRS DEFAULT="/usr/local/share:/usr/share" OVERRIDE="${XDG_DATA_DIRS}"
XDG_DATA_DIRS DEFAULT="@{HOME}/.local/share:${MY_DATA_DIRS}
?
Online
Hi seth, thanks for the reply!
Unfortunately, this gives me the same result as my previous attempt, namely:
MY_DATA_DIRS is assigned "/usr/local/share:/usr/share" (because XDG_DATA_DIRS is empty) [good]
XDG_DATA_DIRS is assigned "/home/ayekat/.local/share:/usr/local/share:/usr/share" [good]
Since MY_DATA_DIRS depends on XDG_DATA_DIRS (in its DEFAULT), that assignment triggers again, so MY_DATA_DIRS is now set to what's in XDG_DATA_DIRS [uhm...]
Since XDG_DATA_DIRS depends on MY_DATA_DIRS, that assignment triggers again, so XDG_DATA_DIRS is now "/home/ayekat/.local/share:/home/ayekat/.local/share:/usr/local/share:/usr/share" [bad]
... etc [bad]
I think PAM stops after three iterations, to avoid an endless loop, and I end up with XDG_DATA_DIRS being
/home/ayekat/.local/share:/home/ayekat/.local/share:/home/ayekat/.local/share:/usr/local/share:/usr/share
I mean, yes, the fallback value for XDG_DATA_DIRS is not hardcoded.
But I would need to ignore the fact that I've got the same path in there three times and that I'm exploiting the fact that PAM aborts an endless loop halfway through
Offline
and if you go for a single step:
XDG_DATA_DIRS DEFAULT="@{HOME}/.local/share:/usr/local/share:/usr/share" OVERRIDE="@{HOME}/.local/share:${XDG_DATA_DIRS}"
?
Online
In that case, the value in OVERRIDE is never empty (even if XDG_DATA_DIRS is initially empty), so DEFAULT is never used.
We also get the "aborted infinite loop" again:
XDG_DATA_DIRS is assigned the OVERRIDE:
"/home/ayekat/.local/share:"
This triggers the assignment itself, because XDG_DATA_DIRS depends on XDG_DATA_DIRS (again, the OVERRIDE):
"/home/ayekat/.local/share:/home/ayekat/.local/share:"
This triggers the assignment itself, because XDG_DATA_DIRS depends on XDG_DATA_DIRS (again, the OVERRIDE):
"/home/ayekat/.local/share:/home/ayekat/.local/share:/home/ayekat/.local/share"
I'll try to ask on the PAM mailing list and will report back if I/they find something.
Thank you so far for your replies!
--edit: Waiting for a reply now.
Last edited by ayekat (2017-06-14 10:16:21)
Offline
Isn't it usual to have XDG_DATA_DIRS for system-wide settings and then a single per-user directory with XDG_DATA_HOME? Why would there be need for two different user directories? Services that use to .local/share regardless of XDG_DATA_HOME won't care either way.
Last edited by progandy (2017-06-12 22:04:14)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I would like to have a FHS-like structure in my ~/.local. I recreate what's in /usr/local + the equivalent of /var.
So I have the following directories:
~/.local/bin ← PATH
~/.local/etc ← XDG_CONFIG_HOME
~/.local/include
~/.local/lib ← LD_LIBRARY_PATH
~/.local/opt
~/.local/share ← XDG_DATA_DIRS
~/.local/srv
~/.local/var/cache ← XDG_CACHE_HOME
~/.local/var/lib ← XDG_DATA_HOME
~/.local/var/log ← XDG_LOG_HOME (does not exist, unfortunately, but I set and use it anyway)
This may sound ridiculous, but it allows me to `make install` programs into ~/.local, and it allows me also to keep my home directory clean (by keeping everything in a single "dot-directory").
If I'm not mistaken, XDG_DATA_DIRS is for static data (i.e. files that will not be modified by the application, but only read) whereas XDG_DATA_HOME contains the variable "state" of an application. I would like to keep those two separate.
--edit: In hindsight, I realise I should perhaps have stated this in my original post, too. I feel like I've started an XY-problem thread here. I'll fix it.
--edit2: Fixed. I apologise.
Last edited by ayekat (2017-06-12 23:04:39)
Offline
Hopefully this doesn't count as too bad of necroposting, but I thought I'd share my experience when trying to set my $PATH via PAM, as it sheds some light on the situation in this post.
Firstly, specific to $PATH, you need to adjust /etc/profile, since that sets $PATH in a way that will override anything set by PAM. You can replace it with a line in /etc/environment.
With that out of the way, let me describe some behaviors I noticed:
(1) When $PATH was not set by /etc/environment, but I tried to set $PATH=...:$PATH in my ~/.pam_environment, the behavior mentioned in this post would trigger. My overrides would happen 3 times each. This happened when using both the PATH DEFAULT=... and the PATH OVERRIDE=... syntaxes (I didn't try with both specified).
(2) When $PATH is specified in /etc/environment, this behavior actually goes away, and everything works as expected (with both DEFAULT= and OVERRIDE=).
This leads me to think that PAM might have a bug in it, though I'm not sure enough about its specification to be sure. If you have root access, you can work around the bad behavior by defining the default value for XDG_DATA_DIRS in /etc/environment, and then using either the DEFAULT= or OVERRIDE= syntax to set your personal overrides in ~/.pam_environment.
Offline
I'm not sure what the bug is supposed to be -- that your shell initialization files are loaded after pam_env and overwrite it?
And yes, /etc/profile is loaded by *your* shell, after the user login.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Sorry I wasn't clear. The note involving /etc/profile is just there in case somebody (like I had) stumbles on this when trying to work through their own issues. It's otherwise completely unrelated to this topic, and I should have clarified that better.
The possible bug I was referring to is the following strange difference in behavior: if you set a variable (PATH, or XDG_DATA_DIRS, or whatever) in /etc/environment, and then set it self-referentially in your ~/.pam_environment, then everything works as expected. But if you remove the line from /etc/environment (effectively meaning PAM hasn't set your variable before getting to the self-referential line in your ~/.pam_environment), then PAM will expand the definition three times, and you get strange situations like the OP's.
Last edited by slipperyfrob (2017-07-30 14:45:17)
Offline
Hehe. I may have misread that a bit.
...
AFAIK there is nothing strictly wrong there, though. Whyever ayekat's initial discoveries happen, it makes sense that /etc/environment is loaded separately from ~/.pam_environment
The problem is when you then have a single pam_env specification that has lines which attempt to reference each other.
So I can see why moving one of them into the system file would prevent that loop.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I do realise that this thread has now mostly become a rotting corpse and hence this might be considered necroposting, but please allow me to give this thread a proper final burial. A "necroburial", if you will.
First, I've stopped the XDG_DATA_DIRS nonsense a while ago (I dialed back my opinionated take on the XDGBDS a bit and concluded that this is not necessary). The issue described here is therefore no longer relevant for me.
More importantly, however, PAM has now officially deprecated reading ~/.pam_environment and that feature might disappear soon anyway, so this thread here is now pretty much irrelevant for anyone.
I've marked the thread as "wontfix". Thank you for the responses, nevertheless!
Offline
In general, posting to a thread for which you are the original poster does not fully fall into the necroposting category as, by demonstration, the OP has not forgotten about the thread.
You make good points as to why this is moot. I shall use this opportunity to close this old thread; let us know using the report link should you wish it reopened.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Pages: 1
Topic closed