XDG Base Directory Specification

Tinu Weber takeya at bluewin.ch
Sun Mar 29 23:17:12 CEST 2020

On Sun, Mar 29, 2020 at 22:47:04 +0200, Serpent7776 wrote:
> On Sun, 29 Mar 2020 22:18:23 +0200 Tinu Weber <takeya at bluewin.ch> wrote:
> >
> > On Sun, Mar 29, 2020 at 13:37:44 +0200, Serpent7776 wrote:
> > > You can set up a local alias instead of setting env variable for all
> > > applications:
> > > for bash that would probably be
> > > 
> > > alias pass='env PASSWORD_STORE_DIR=/some/dir pass'  
> > 
> > Setting shell variables only applies to the interactive shell, so the
> > this will be of rather limited use.
> > 
> > In my case pass is almost exclusively invoked not manually, but through
> > other ways, e.g. with passmenu, or as part of an application
> > configuration file (mutt, msmtp, mbsync, irssi, ...).
> > 
> > In all those cases, an alias wouldn't have any effect, and setting an
> > environment variable is AFAIK the only agnostic way for achieving XBDS
> > compliance there.
> If pass is executed not directly, but by passmenu, then one can execute `env PASSWORD_STORE_DIR=/some/dir passmenu` and pass
> should inherit the variable.

Sure, but with that approach, we just move the issue one level up. And
as I've mentioned previously, I've got more than one application
interacting with pass, so I'd have to apply that fix in multiple
locations now.

A global environment variable is still cleaner and less of a maintenance

But this then leads to the issue that Nicolai has mentioned. At the
moment of this writing, I've got... 26 environment variables and 12
wrapper scripts all for making various applications adhere to the XDG
basedir spec.

So while defining environment variables is a rather low-effort
workaround, it still piles up. Personally, I'd welcome it if I could
scratch pass off the list of applications that need a workaround.


More information about the Password-Store mailing list