Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
Le 27.11.2014 03:04, Serge a écrit :
Later some people started to abuse those directories and put there
files,
that never supposed to be there. Those people don't really think
about
standards or unification. Usually they just enable displaying hidden
files
in their file manager, see a lot of dotfiles in a home directory and
think
that "this is wrong". They start searching how to "fix" this, find
xdg
basedir-spec, and use it as an excuse for moving ~/.appname files, to
~/.config/appname, or worse, split them among .config, .local,
.cache...
If only rogues can put their configuration files in a subdirectory of a
common directory, then every application is a rogue, since all
applications put their configuration files in the $HOME directory or any
of it's subdirectories.
The point is that, applications using $HOME instead of $XDG_CONFIG_HOME
does not only put their configuration there, but all their files. So,
thanks to those ones, you will have things like: .bashrc, .bash_history,
.dmenu_cache, .prxAEIHar (try to guess what's this file? I myself have
no idea... reading it, it seems it's related to xosview?) etc.
Ok, now, you only want to save your configuration files. Which ones
will you take? Or, for a reason you want to use an application which is
not installed on your system, but in a remote file system that you can't
access everytime. If this application puts everything in $HOME, then
you'll have useless things on your local machine, but if it uses XDG
directories, you can mount/bind/whatever the distant directory to a
point in $XDG_CONFIG_HOME.
Another nice thing:
Imagine I use several softwares which are not pieces of an existing
monolithic DE.
Imagine I would like to write an application to manage configuration of
those applications I am using.
I will probably have to use the strategy design pattern[1] because
configuration formats will differ (key=value in INI-style way,
xml-erk-style format...) and have plug-ins to manage those formats, but
there are quite common ways, easy to parse, like good ol' INI (like
gftp, but you'll probably find many others lying around on your own
computer), or ugly (my opinion) XML.
Ok, so, we sometimes have common formats, which might be used by
several applications I use. So, maybe we could find some which shares
common features? Like, for example, binding a shorcut to open a file
(pretty common, right?) or move your character in an FPS game?
For this, I could ask my plug-ins to extract, in all configuration
files of $XDG_CONFIG_HOME, everything which looks like being able to
open a file (some regexes on the key's name should do the work in many
cases), and refer the folder's name which contains the files to identify
which software uses it.
Then, I could ask the user if he want to define a new shortcut for some
specified set of applications (or to all? Why not?).
Ok, then, now, the user can have a way to configure everything on his
computer, without those applications having been written to be integrate
in any DE. Of course, DEs can use it too, but, I made the choice to not
use such things, because I think that there is too much bloat.
This would be harder, by far, if every application just puts things,
sometimes in $HOME/.application, or $HOME/.application.conf, or
$HOME/.application/config or $HOME/.application/application.config (not
to speak about those nasty rc files!).
Last but not least, it means that one could write a library to manage
configuration files, which could be reused, because things goes in some
predefined places, in a predefined order. No need to learn that
.bash_profile is read before .profile... oh, sorry, bash does not uses
XDG dirs.
So, I can see advantages. Several ones.
I'll try to find the problems now: the application have to be made
correctly enough to not trust the content of an environment variable,
because it may try to trick the software, for buffer overflows, code
injections, or less dangerous things like behavior changing depending on
the moment, if the application re-read the environment variable.
That's all I can find.
They don't think about /etc/xdg, they don't read FHS or other XDG
standards,
Well... honestly, I would not follow FHS blindlessly, obviously.
Because, well... it does not works on Microsoft Windows, first, which is
a widely used system, and I prefer to make things portable (so I would
use a different mechanism on windows than on Debian to read default
configuration files) plus, FHS is not followed in the same way
everywhere: in *BSD, I think the softwares you will install through the
package manager will not go into /usr/bin, but in /usr/local/bin. On
some linux distro, it may go in /opt. How could I know? Even UNIX-style
OSes disagree!
About other XDG standards, well... I do not have to use dbus stuff to
know what directory I should use to store my specific user's
configuration, right?
they don't care about people who have to do 2-4 times more work to
find and
migrate settings of selected application to another machine, they
just
don't want to see dotfiles.
Hum... If you put your configuration files in $HOME/.config, then if an
admin wants to save the configuration, he just have to copy this folder,
no need to copy bash's history, or .xsession-errors. Definitely, XDG is
here far better than what those tools does.
But don't blame XDG standard for that, blame people abusing it
to reduce the number of dotfiles in their home directory.
There may be applications abusing it to "reduce the number of
dotfiles". Or there may be application's authors which try to avoid the
users (which can be other applications) the pain to search in 100 dotted
files which ones are configuration files, which ones are configuration
backups, wich ones are folders which includes configuration files, which
ones are log files, which ones are data files.
1: this is a pattern which allows to change behavior depending on
situation, without modifying caller all the logic to add a switch/case
or something like that. Can be useful to write plug-in based softwares
for example: http://en.wikipedia.org/wiki/Strategy_design_pattern
Reply to: