please conform to the xdg base directory specification

please conform to the xdg base directory specification

[Thomas Koch]

The XDG base directory specification[1][2] says that configuration files should 
go in ~/.config/$APPNAME. I know that it's possible to change $ZDOTDIR in /etc 
but this would break the zsh configuration for all users that have not moved 
their config files. So zsh would need to check both $HOME and $HOME/.config/zsh 
for configuration files.

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[2] https://wiki.debian.org/XDGBaseDirectorySpecification

Regards, Thomas Koch

Re: please conform to the xdg base directory specification

[Frank Terbeck]

Thomas Koch wrote:
> The XDG base directory specification[1][2] says that configuration files should 
> go in ~/.config/$APPNAME. I know that it's possible to change $ZDOTDIR in /etc 
> but this would break the zsh configuration for all users that have not moved 
> their config files. So zsh would need to check both $HOME and $HOME/.config/zsh 
> for configuration files.

I'd see if your login mechanism can't do that for you. With PAM, you
should be able to put ZDOTDIR="${HOME}/.config/zsh" into
`~/.pam_environment'. So that should also work on a per user basis. See
`pam_env(8)' and `pam_env.conf(5)' for details.

Regards, Frank

Re: please conform to the xdg base directory specification

[Peter Stephenson]

Adding yet more complexity to the initialisation file logic doesn't seem
a great idea, but one thing that could keep everything more or less
under control would be to make ZDOTDIR a colon-separated array (and make
zdotdir an array).  This adds a lot of flexibility in a place users
would already expect to find it.  The only disadvantage I can see is if
you happen to have a directory with a colon in it, which is unusual and
bad for other reasons.

We'd need to decide on the rule for multiple directories: use the first
found, use the first containing initialisation files, use the first file
of each type found by searching through the path...

An empty directory would be equivalent to $HOME.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: please conform to the xdg base directory specification

[Bart Schaefer]

This is the second "please conform to XDG" thread in the last few months
(last time was users/17726).  I mention this because ...

On Aug 15,  7:54pm, Peter Stephenson wrote:
}
} Adding yet more complexity to the initialisation file logic doesn't seem
} a great idea, but one thing that could keep everything more or less
} under control would be to make ZDOTDIR a colon-separated array (and make
} zdotdir an array).

... this suggestion, while fine on its own, does not solve the problem of
bootstrapping the value of ZDOTDIR, so zsh would still not "conform to
XDG."  Unless someone *else* has a good use for a multi-element ZDOTDIR
path, there's no benefit in going down this road.

Unless of course you're proposing a default of zdotdir=(~/.zsh ~) rather
than the current default of unset, a change that has its own set of
potential gotchas.

} We'd need to decide on the rule for multiple directories: use the first
} found, use the first containing initialisation files, use the first file
} of each type found by searching through the path...

I'd prefer "use the first found" so that dotfiles could be disabled by
creating an empty directory.  I don't think "first file found of each
type" is a wise idea, the files in a particular directory are likely to
be related and not necessarily meant to work with files found elsewhere.
"First directory containing" would be OK, but means scanning for all the
files as soon as any of them is needed.

} An empty directory would be equivalent to $HOME.

Is "." or anything containing the quivalent of a leading ".." allowed to
appear?  I tend to think anything not beginning with "/" should just be
ignored.

Re: please conform to the xdg base directory specification

[Mikael Magnusson]

On 17 August 2013 05:20, Bart Schaefer <schaefer@brasslantern.com> wrote:
> This is the second "please conform to XDG" thread in the last few months
> (last time was users/17726).  I mention this because ...
>
> On Aug 15,  7:54pm, Peter Stephenson wrote:
> }
> } Adding yet more complexity to the initialisation file logic doesn't seem
> } a great idea, but one thing that could keep everything more or less
> } under control would be to make ZDOTDIR a colon-separated array (and make
> } zdotdir an array).
>
> ... this suggestion, while fine on its own, does not solve the problem of
> bootstrapping the value of ZDOTDIR, so zsh would still not "conform to
> XDG."  Unless someone *else* has a good use for a multi-element ZDOTDIR
> path, there's no benefit in going down this road.
>
> Unless of course you're proposing a default of zdotdir=(~/.zsh ~) rather
> than the current default of unset, a change that has its own set of
> potential gotchas.
>
> } We'd need to decide on the rule for multiple directories: use the first
> } found, use the first containing initialisation files, use the first file
> } of each type found by searching through the path...
>
> I'd prefer "use the first found" so that dotfiles could be disabled by
> creating an empty directory.  I don't think "first file found of each
> type" is a wise idea, the files in a particular directory are likely to
> be related and not necessarily meant to work with files found elsewhere.
> "First directory containing" would be OK, but means scanning for all the
> files as soon as any of them is needed.

I have my dotfiles in ~/.zsh, but .zshrc linked to ~ so I can edit it
easily (I tend to do that a lot), so parsing both by default would be
bad for me.

-- 
Mikael Magnusson

Re: please conform to the xdg base directory specification

[Peter Stephenson]

On Fri, 16 Aug 2013 20:20:19 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 15,  7:54pm, Peter Stephenson wrote:
> }
> } Adding yet more complexity to the initialisation file logic doesn't seem
> } a great idea, but one thing that could keep everything more or less
> } under control would be to make ZDOTDIR a colon-separated array (and make
> } zdotdir an array).
> 
> ... this suggestion, while fine on its own, does not solve the problem of
> bootstrapping the value of ZDOTDIR, so zsh would still not "conform to
> XDG."  Unless someone *else* has a good use for a multi-element ZDOTDIR
> path, there's no benefit in going down this road.

Presumably if you wanted your distribution to conform to it you'd stick
the setting in /etc/zshenv, with appropriate protections.  I expect we'd
have to issue guidelines if we went down this route since there are still
plenty of pitfalls.

Mikael wrote:
> I have my dotfiles in ~/.zsh, but .zshrc linked to ~ so I can edit it
> easily (I tend to do that a lot), so parsing both by default would be
> bad for me.

Whatever the rule we came up with was, I'm sure there'd be a way of
dealing with this.

Either look for the first existing directory.  (So it wouldn't be
sensible to have $HOME anywhere other than at the end.)

Or look down $zdotdir for the first existing dot file and
stick with that directory for all files.  (Probably needs special
handling if zdotdir gets changed.)

Or look for the first dot file of each type separately down $zdotdir.  This
is the simplest solution but could have counterintuitive results if you
leave an old file behind in $HOME and subsequently only ever look at
the files in ~/.zsh or wherever.

There doesn't seem any good reason for handling multiple files of the same type within $zdotdir (i.e. .zshrc etc. in two different places), there are already plenty of good ways of chaining files.

We might need to think about rules for finding e.g. ~/.zsh/zshrc instead of
~/.zsh/.zshrc since the extra dot is pretty unhelpful.  (E.g. look for
the file without the dot if a parent directory does have a dot at the
start.  We don't want to look for ~/zshrc, that could easily be problematic.)

If there's no real enthusiasm, however, it's not worth pursuing.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/