XDG Base Directory Specification

[Serpent7776]

On Sun, 29 Mar 2020 23:17:12 +0200
Tinu Weber <takeya at bluewin.ch> wrote:

> 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.
Correct
 
> A global environment variable is still cleaner and less of a maintenance
> burden.
Wouldn't call it cleaner, but that's subjective.

> 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.
That's why I would not pollute global env just for single application.

> 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.
Note that I'm not telling such change is a bad idea.

Regards
-- 
/*
 * Serpent7776
 */