[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: