Convention Over Configuration: A Way Forward?
kevin.krammer at gmx.at
Mon Jan 9 04:53:49 PST 2012
On Monday, 2012-01-09, Thiago Macieira wrote:
> On Sunday, 8 de January de 2012 17.49.12, Trans wrote:
> > I mean that they don't use the environment variables.
> I really don't think the environment variables are an issue.
> As Kevin said:
> > > Hmm. I haven't done any application with just low level APIs but
> > > reading an
> > > environment variable and a string comparison seems indeed rather
> > > trivial to
> > > me. Though I can only speak for languages I've used so far, e.g.C/C++,
> > > Java,
> > > Python. Might be more complicated elsewhere.
> Getting the value of an environment variable and applying a default if it's
> not set is the least of the issues. They *already* have to do that for
> $HOME if they want to save their configuration files in the home
> directory, with fallback to values read from the password database.
Right, I didn't consider that they already have to read an environment
But maybe they consider $HOME to be always set or only explicitly unset, i.e.
always just do
config_path = getenv( "HOME" ) + config_name
If that would be the case specifying XDG_*_HOME should be always set would
> For that reason, I don't think you're addressing the source of the problem.
> It's more likely that they don't know that the option exists in the first
> place, that they are lazy to change their code, or they simply don't want
> to change from old Unix convention. Neither of those problems will be
> solved by hardcoding the path to $HOME/.config.
My theory as well. Hence my original question on whether there is any evidence
to the contrary.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the xdg