Hacker News Reader

Comment by keyist | Hacker News Reader

Instead of putting a dotfile or dotdir in the user's home directory, do follow the XDG Base Directory specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-l... .

It's easy to understand and requires only a marginal increase in effort/code.

View on HN

I see no benefit.

It's not at all easy to understand, nor easy to implement, nor does it have any tangible advantages.

It's one of these superfluous pseudo-standards that do nothing but add needless clutter. But gladly nobody seems to be using it anyway, I see only one directory in my ~/.local: vlc.

Check out your .config and .cache directories.

I consider it good practice to allow users to customize where your program creates files. I don't like $HOME to be the default dumping ground for anything I run.

A standard that uses environment variables means programs don't have to provide extra options for this customization (I've seen -f,--file , -c,--config and other variants). It allows for common code (libraries that implement the spec).

If you poke around for feature requests for various open source programs, you'll find XDG basedir compliance come up occasionally (moreso for CLI utils). I wouldn't say "nobody seems to be using it"; quick scan of my folders includes Chromium, uzbl, htop. Git's next release will be compliant too.

I don't particularly like dumping everything in home, but XDG is worse. Now, if I want to start over with a clean profile, there's a whole list of locations I have to zap. Spraying shit in three directories is worse than one.

my problem with that "one" directory is that i have to take care specifically to back it up. applications that at least use ~/.cache means i don't have to worry about backing up a bunch of useless stuff.

Isn't that what /tmp is for? Why not put cache files into /tmp/<username> with 0700 permission?

No, that's not necessarily what /tmp is for.

Consider a browser cache. /tmp is not guaranteed to be preserved between program invocations[1]. /var/tmp [2] might be a better place. /var/cache [3] is intended for exactly this kind of thing.

Unfortunately, it can be far more useful for an administrator in a multi-user setup to want user-specific caches in home directories. That way, you get all of the infrastructure for managing user data for free, like quotas.

Also note: if you're considering putting data into /tmp or /var/tmp, please honor the TMPDIR environment variable, if it is set[4].

[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFIL...

[2]: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARY...

[3]: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICA...

[4]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

> If you poke around for feature requests for various open source programs, you'll find XDG basedir compliance come up occasionally (moreso for CLI utils).

What fraction of those requests are by XDG advocates?

I ask because every standard comes with folks insisting that it be followed. While those folks claim to represent the interests of users, those requests are different.

I have made this specific feature request on an application (Mangler) and I have no affiliation with XDG.

~/.local isn't primarily where you should look; check ~/.config

It's only used by those few users that use SSH.

? ssh keeps its files in ~/.ssh.

  [jlgreco@local] ~ % find ~/.config ~/.local | grep ssh | wc -l
  0

So.. no.

Actually, it is in considerably wide use for desktop linux applications.

It definitely has tangible benefits as well -- it promotes the clear separation of app data and user configuration, and unclutters the home folder.

And as pointed out by other replies, ~/.local is not the only XDG data dir.

I'm curious, how do you find it not easy to implement?

I see no benefit.

How about consistency?

When there are forty years of existing applications using ~/.appname?

You are running a modern linux distro with only one file/dir in .local?

% cd ~/.local

cd: no such file or directory: /home/tammer/.local

% uname -s -r

Linux 3.4.7-1-ARCH

FreeBSD 7.1-RELEASE - No ~/.local, ~/.config

FreeBSD 9.0-RELEASE - No ~/.local, ~/.config

Linux 3.2.0-23 - No ~/.local, ~/.config

Linux 3.0.0-16 - No ~/.local, ~/.config

Linux 3.0.0-12 - No ~/.local, ~/.config

Honestly, I'd never even heard of this scheme before today.

I guess I should have said "a modern linux desktop environment." Are these shell boxes or desktops? In my experience the majority of propgrams that use this spec are gtk/qt programs.

PS Listing a kernel version does not really provide any information about your modern linux distro.

Interesting... I have ~/.cache, ~/.local and ~/.config and all 3 of them have quite a lot of subdirs and dotfiles inside.

> I see no benefit.

The first benefit is that it removes clutters from your $HOME.

The second benefit is that you can now manage and backup your settings in a sane way.

* ~/.config contains config files (should not be lost, but if lost you can recreate them);

* ~/.local contains user data files (save them often, never lose them for they are not replaceable);

* ~/.cache contains cached information (can be tmpfs mounted, you can delete it any time you want, no loss in functionality, you just lose some optimization);

* ~/.run is for temporary system files (must be tmpfs mounted or it must be cleaned during at shutdown or power on).

Luckily most of the apps used on Linux systems now use it, you are probably using Mac OS X.

> The first benefit is that it removes clutters from your $HOME.

Invisible clutter? That's a strange concept.

But the rest of your point indeed makes sense. It still is easier and probably comment to backup the whole $HOME. But those points you can see as a benefit, though not obvious.

As Rob mentions in his post, the more dotfiles there are in $HOME the slower path resolution for any subfiles becomes. How do we navigate to ./src? We open the directory and read all the entries until we find the one called "src". What happens if we encounter a morass of dotfiles beforehand? src takes a while to find. The clutter may be invisible to you, but it does gum up the works.

Unless you have many thousands of files, I can't imagine you would ever notice a slowdown.

For what it's worth, most modern file systems (JFS, XFS, ext4, reiserfs, btrfs, ...) have logarithmic (or better) directory lookup times. This is achieved using hashes and b-trees (or even hash tables).

Fair point. Though anything using the standard POSIX dirent API would still get the performance hit (even if path resolution doesn't).

It's not invisible when you're actually looking for an invisible file.

All of your points are invalid for a simple reason: Almost no software uses this fancy standard.

And for the backup-case: Whitelisting is usually a futile idea to begin with. Normally you'd prefer to backup the odd superfluous file rather than miss an important one.

Luckily most of the apps used on Linux systems now use it

Excuse me?

  $ find ~ -maxdepth 1 -name ".*" | wc -l
  228

  $ find ~/.local | wc -l
  4

  $ uname
  Linux

I counter your anecdote with my anecdote:

  $ find ~ -maxdepth 1 -name '.*' | wc -l
  354
  $ find ~/.local/ -maxdepth 1 | wc -l
  3
  $ find ~/.local/share -maxdepth 1 | wc -l
  66
  $ find ~/.config/ -maxdepth 1 | wc -l
  108
  $ find ~/.cache/ -maxdepth 1 | wc -l
  803
  $ uname
  Linux
  $ lsb_release -d
  Description:	Ubuntu 12.04 LTS

That's interesting, and sort of disturbing.

My box is not a desktop, so that's probably the difference. I still find that scheme an atrocity.

When going to that length they could at least have settled for one directory (~/.appdata or whatever). Half-baked is the most polite description I can come up with.

But all those folders are different, so a single one would be annoying (or: require two layers.)

.config can be posted online, and shared with others (like the many "dotfile" repos you'll see on github)

.local needs to be backed up, and may have private data.

.cache can be blown away (or tmpfs.)

.run MUST be blown away on restart.

This is simple, sane, and works well.

Yes, if you push me like that I'll say it: it's incompetently overdone.

When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?

And when I delete an app then I have to look in all of them? That is just utterly backwards for no conceivable reason.

Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away). This will by definition be fragile and have funny corner-cases in the first few iterations. Also what happens when ".run" is not blown away, like on a system that does't implement this nonsense?

The definitions are blurry and complex, many apps will get them wrong (.local vs .config etc.).

Unix already has a location for temp files. It's called /tmp.

And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.

When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?

I can see a clear and very useful difference between RUNTIME_DIR, CACHE_DIR, and CONFIG_DIR. Consider a scenario where $HOME is on a networked filesystem. RUNTIME_DIR has to be outside that, and local to the machine's namespace. That's because it references things inherently local to the machine. That is, pids and pipes. These wouldn't make sense on any other machine and will just make the application's job harder.

I also set CACHE_DIR to be local (/tmp/$USER.cache.) That's because caching performs terribly when it's flying over the network. Chrome is the main culprit for me. It also fills my file quota with hours of using it. However, it's still useful to keep that data in the medium term.

CONFIG_DIR and DATA_DIR, however, don't seem to be very different to me. I can't imagine a scenario where I want one but not the other. I might be using the wrong sort of applications. (For the record I have 8 files in .config, 10 dot files, and just 1 in .local/share.)

Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away).

Having RUNTIME_DIR on a tmpfs, like what most distributions do with /var/run, solves that problem. I map mine to /var/run/$user, even though I've yet to see an application actually use it. The spec BTW doesn't even specify the default value!

And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.

I agree, the default values are silly. This, like most of Modern Unix, is an ugly hack which makes dealing with the rest of the ugly hacks a bit easier. If you want an elegant solution you'll probably have to throw away most of what was added during last 20 years. May I suggest starting with sockets?

   % uname
   Linux
   % find ~/.local | wc -l
   16824
   % find ~ -maxdepth 1 -name ".*" | wc -l
   279

> % find ~/.local | wc -l

Missing something?

    find .local/  | wc -l
    618

So I guess it depends on your Linux flavor. Mine is Ubuntu 12.04.

I am always pleasantly surprised when programs follow XDG. One notable example is the fish shell. Most shells put dotfiles in $HOME, like .bash_profile or .zshrc. Fish puts everything in .config/fish/.

Somehow .dotfiles work just fine under Windows :). As such they are somehow more "portable"

Emacs saves them under %USERPROFILE% - I have in there - .alice, .android, .easyhg, .eclipse, .gstreamer-0.10, .lighttable, .m2, .matplotlib, .... .VirtualBox, .zenmap

Also in "Application Data" - .emacs.d, .mc, .subversion

My point is - this system works somehow even under non-unixy systems.

Because it's simple.

%APPDATA% is as simple as home but much better on the clutter front.

True. I actually kinda like the Windows directory structure since Vista. If only the application devs would also follow the standard (hence the whole My Documents mess).

It didn't use to work. I think it was added for XP SP2 or so, probably due to the popularity of manu *nix ports like Emacs.

It always did, at least in NTFS.

What did not, and still does not, is to create them via Windows Explorer.

You can create them just fine from the command line, or via Windows APIs.

You can create them in Windows Explorer with a little trick: type the name with a trailing dot. Entering ".vimrc." will save as ".vimrc", no trailing dot.

Great! I was not aware of it.

Incidentally, Emacs will use %UserProfile%\.emacs.d if you set %HOME% to %UserProfile%, which, as a UNIX user, I personally prefer for consistency. While not Emacs-specific, another trick I've found useful is that, on 64-bit Windows, you can open %SystemRoot%\System32\somefile in 32-bit Emacs iff you refer to it as %SystemRoot%\sysnative\somefile (the original path yields %SystemRoot%\SysWOW64\somefile).

I would have preferred if it did not rely on environment variables since almost nobody sets them which means there will be untested code in applications implementing the specification.

Where possible, applications should rely on tested libraries to implement the specification, like PyXDG.

I notice the $XDG_DATA_HOME environment variable isn't set in my Intrepid install. Maybe its set in later Ubuntu version.

But the value not being set for me means implies to me that it not being set is pretty common. Thus it seems like supporting this standard is going to involve supporting a fall-back of whatever you would do otherwise.

So I don't see "easy" at all but rather extra BS. Sorry.

From the spec: If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. Similarly there's a default (.config/) defined for XDG_CONFIG_HOME. So the fallback is well-defined rather than "whatever you would do otherwise".

Also, for my 2c, you should consider updating your Intrepid install if you at all can. It hasn't been supported for over two years, so it hasn't seen any security updates in that time. The Ubuntu do-release-upgrade system is pretty easy and reliable.

$HOME/.local/share doesn't exist on OSX either.

If it does not exist, you've not used a soft using it. I have one.

Not much of a standard then - I have done hundreds of installs.

XDG is a freedesktop standard. Meaning: checking that standard on OS X is a bit strange.

I thought we were talking about unix, not the "free desktop standard".

On my system (Xubuntu), these environment variables are empty. Seems not to be much of a standard.

To be fair, that's how it works. They have default values when they're not set. These are for when you want to override them, e.g. to keep cache files local instead of over your net mounted home directory.

Reply on news.ycombinator.com