1. 38
    Practical Self-Defense against the Scourge of Dot-Files ☶ linux
    soc avatar authored by soc 5 years ago | 22 comments

Here are a few practical steps for user that are fed up with applications littering in their home directory:

Step 1: Adjust some environment variables

Add the following line to .pam_environment:

  ICEAUTHORITY DEFAULT=${XDG_RUNTIME_DIR}/ICEauthority.

Add the following lines to /etc/lightdm/lightdm.conf (if you use LightDM)

  [LightDM]
  user-authority-in-system-dir=true

or try adding

  XAUTHORITY DEFAULT=${XDG_RUNTIME_DIR}/Xauthority

to .pam_environment (this might or might not work depending on the display manager).

Step 2: Check whether applications support the XDG base directory spec

Check whether existing dot-files and dot-directories can be moved – many applications already support the XDG base directory specification, but do not move existing files:

  • Rename an application’s dot-files/dot-directories, start the application and check whether the application created entries for itself in .config or .cache.
  • If this is the case, migrate existing dot-files to those directories (likely renaming them in the process).
Step 3: File bug reports

Check whether bug reports exist for the remaining applications or file new bug reports. The Arch wiki entry on XDG Base Directory support is an invaluable resource.

Step 4: Make $HOME read-only (yes, really)

Run

  chmod -222 $HOME

to prevent the creation of new dot-files and dot-directories in your home directory.

From this point on, the number of dot-files and dot-directories can only shrink as the remaining applications get fixed and start conforming to the XDG base directory spec, while no new dot-files and dot-directories can be added to your home directory.

    1. 16
      peter avatar peter 5 years ago | link

      Or you could give up and not care.

      $ ls -d ~/* ~/.* | wc -l
252

      And for the neatness masochists:

      $ ls -d ~/*test*  | wc -l
37
      1. 6
        soc avatar soc edited 5 years ago | link

        I decided to share a solution because it is working so nicely on my system.

        I’m down to a single dot-file and 26 dot-directories on my system, so it is certainly working.

        1. 6
          peter avatar peter 5 years ago | link

          I appreciate you sharing. It’s a good thing to be aware of, and certainly valuable for people who do like to be more organized. But personally I have no gripe with chaos, and prefer systems that are searchable over structured. And I prefer ease of access to the extent that I will symlink dirs I’m using into my home dir, making it even more cluttered. I think you can guess how often I garbage collect these symlinks. ;)

      2. 2
        4ad avatar 4ad 5 years ago | link

        I agree, there are much worse things in life to worry about.

    2. 9
      seschwar avatar seschwar 5 years ago | link

      A few other methods:

      libetc is a LD_PRELOAD-able library, which intercepts opening of dotfiles under $HOME and opens them from $XDG_CONFIG_HOME instead.

      rewritefs is a FUSE filesystem which lets you configure rewriting of paths similar to Apache HTTPd’s mod_rewrite. You can configure it to perform a mapping of $HOME/.* to $XDG_CONFIG_HOME/* as well.

      1. 3
        matthias avatar matthias 5 years ago | link

        The description from libetc reads as follows:

        “On my system I had way too much dotfiles […] For easier maintenance I wrote libetc.”

        Really, why should I care? They do not pop up during ls, they will be backuped like all other files and the most important ones live in a git repo. LDPRELOADing a lib just to have a clean $HOME seems a lot like being a Unix Hipster. Or maybe I am getting just old…

    3. 6
      felixgallo avatar felixgallo 5 years ago | link

      What the fuck has happened to Unix?

      1. 20
        cmhamill avatar cmhamill 5 years ago | link

        I like this comment because you could mean it three ways:

        1. What is wrong with kids these days and their XDG crap? Dotfiles are a perfectly good solution and aren’t visible in ls output by default, anyway.

        2. What has happened to Unix, that so many programs need to specify configuration data in $HOME? Well-designed Unix programs should be simple enough to need no configuration in the vast majority of cases.

        3. Hiding files beginning with a . was a terrible idea totally out of whack with the rest of the Unix ethos. It’s up there with filesystem links and BSD sockets for worst additions to the system.

        I vote for option three, but which one were you going for?

        1. 2
          felixgallo avatar felixgallo 5 years ago | link

          1 and 2. . is a hack, but filesystem links were and are a great idea, and bsd sockets is why you are reading this.

          1. 3
            cmhamill avatar cmhamill edited 5 years ago | link

            I mean, on the one hand, fair enough.

            On the other hand, symlinks (in comparison to hardlinks, I should have been more specific) remove the guarantee that the filesystem can be modeled as an acyclic graph. In addition, every program has to handle symlinks: make a decision whether to treat them like the files they point to or like stub files that point to a path name; deal with symlinks to non-existent files; properly follow symlinks to resolve files when needed — it’s not even possible, because of this, to correctly display the current directory in Unix 100% of the time. Bash tries to track where you last were before you ran cd so it acts like you expect, but there’s logic in Bash just for this. The Fish shell, for example, does not do so and always resolves symlinks in the displayed path.

            Sockets are truly terrible, despite being an enabling technology for the Internet. You need a special set of APIs just for sockets, instead of following the Unix precedent and exposing a device file with a standard file API. This argument is more controversial, and others have made it better than I, but BSD sockets siloed network programming off from other kinds of I/O programming in a way that was unnecessary and, I think, left a lot of gains on the table compared to a (virtual) filesystem approach.

      2. 4
        soc avatar soc 5 years ago | link

        Real Unix® operating systems distribute configuration across ~/.app/, ~/.config/app/ and ~/Library/Preferences/org.foo.bar.App.plist, so I’m quite happy with Linux converging on the XDG spec.

    4. 5
      inactive-user avatar inactive-user 5 years ago | link

      … and then make $XDG_CONFIG_HOME an git repository, so you can get your settings managed without needing an extra dotfiles manager.

    5. 4
      cmhamill avatar cmhamill 5 years ago | link

      I’ve taken to setting $XDG_CONFIG_HOME to ~/etc, which just seems obviously correct, in retrospect.

      1. 2
        soc avatar soc edited 5 years ago | link

        Why not $XDG_CONFIG_HOME=$XDG_DATA_HOME/../etc/?

        I think that would look nicely with the pattern of having $XDG_DATA_HOME/../bin/ as an additional $PATH entry.

        1. 1
          cmhamill avatar cmhamill 5 years ago | link

          I’ve done that before, too, but I find that I reach for things in $XDG_CONFIG_HOME often enough that it got annoying. At this point, I feel slightly more likely to set $XDG_DATA_HOME to ~/share. I already have ~/bin, but I tend to make a Debian package out of most tools I write once they stabilize, anyway. I just need to find a good place for $XDG_CACHE_HOME, which I currently have set to ~/.local/cache. It’s the one XDG directory whose contents I never care to get at easily, but I also need to be on reliable storage. I might stick it somewhere in /var/tmp/$(uid) or whatever the one that the FHS says should persist across reboots is. I could just commit to my bull shit and use ~/var/cache, though. Or just ~/var, since it will be the only directory in there. ~/cache feels the most “correct” but also really aesthetically terrible. Oh well.

      2. 1
        steveno avatar steveno 5 years ago | link

        How is that correct? Everyone who logs in all get the same configs. The whole point of dot files in ~/ was so it would only affect you.

        1. 2
          cmhamill avatar cmhamill 5 years ago | link

          There’s still a tilde, just not a dot.

          1. 2
            steveno avatar steveno 5 years ago | link

            You’re right. I completely missed that.

    6. 4
      Diti avatar Diti edited 5 years ago | link

      You are referencing PAM and display managers, but as far as I know, they don’t exist on macOS. Would you have a more “standardized” (the same way sh is more standard than bash) approach?

      1. 2
        gerikson avatar gerikson 5 years ago | link

        This is a good point, I’ve actually never heard of XDG (I’m a daily user of Windows, OS X, and Ubuntu on a server…)

      2. 2
        soc avatar soc 5 years ago | link

        I don’t really know much about macOS/BSD/other niche systems.

        Setting XAUTHORITY and ICEAUTHORITY to something sensible is only necessary because applications using those variables expect that they can create and delete authority files at the location specified. Without setting those, you wouldn’t be able to make $HOME read-only.

        But if your operating system doesn’t have such applications in the first place, you can just skip this step.

    7. 2
      akkartik avatar akkartik 5 years ago | link

      Ooh, making $HOME read-only is a good tip, thanks.

      Here’s my approach from 7 years ago: https://news.ycombinator.com/item?id=1702108. But my laptop has gotten gnarly in recent times..