Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dotfile madness

0x46.net

Post reply on HN
Print view View original

81–90 of 534 posts

Re: Dotfile madness

#81

Post by yjftsjthsd-h »

sowbug wrote: post #74
bauerd wrote: post #21

I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?

It avoids the realization that you have been paying AWS to back up ~/.cache and ~/.local for the last 6 months.

Point of order: Some of us really want ~/.local backed up or otherwise persisted; I've got the equivalent of a second /usr in there, and I only don't worry about "backing it up" because ~/.local/etc is in version control, and the rest is installed by my setup scripts.

~/.cache can burn, though:)

Re: Dotfile madness

#82

Post by netsec_burn »

sneak wrote: post #80
nine_k wrote: post #72

Earlier quoted context omitted.

Adding an interface to access the tag store won't be very hard. It would be harder to make it so that all the tag-oblivious programs, like mv or vi, to say nothing of rsync, would preserve the attributes when moving or modifying a file.

Sidecar files might work, and would also be filesystem-portable.

This is what Mac does to track download locations, if I remember correctly (._file).

Re: Dotfile madness

#83

Post by capdeck »

bauerd wrote: post #21

I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?

Why eat an appetizer, main course and dessert separately? Just put them in the blender and gulp in the goo... Also because entropy.

Re: Dotfile madness

#84

Post by godot »

avip wrote: post #43

node_modules and yarn.lock etc. in the location where the tool was run is a feature, not a bug. Ask any python user digging to find where pip decided to drop it this time.

I was going to say, I've been actively working with nodejs for a few years and I've never had node_modules, package-lock.json and yarn.lock in my home dir, on either Linux or macOS. If you run npm/yarn commands in your home dir for some reasons, then you should expect those files there. On the less than handful of times where I ran npm in my home dir accidentally, I make sure to immediately go and delete those files.

It's also possible that the author runs a lot of scripts from various projects from github and sometimes those scripts' authors are not careful about running npm/yarn within their projects. I guess I don't play around with OSS enough. :)

Re: Dotfile madness

#85

Post by fiddlerwoaroof »

anoncake wrote: post #64
gryfft wrote: post #38

From a user standpoint, a lot of of unrecognizable things show up if you pass that -l flag. In my opinion, having a conventional place to look for user configuration in plain text is a good thing, not a bad thing, and of course I would want it to be in the directory on my system where I'm the sole owner. As somebody else mentioned, this means backing up my personal settings and files is braindead simple, too. Asking…

> Having a conventional place to look for user configuration in plain text That place is $XDG_HOME_CONFIG (~/.config)

The original convention was dotfiles in $HOME. The $XDG_HOME_CONFIG convention is comparatively new as it was introduced in 2003.

Re: Dotfile madness

#86

Post by cma »

netsec_burn wrote: post #71
nine_k wrote: post #60

Earlier quoted context omitted.

A general tagging mechanism, reasonably supported across filesystems , would be great to have. Not only for media collections. It's not easy to implement nicely, though.

Why wouldn't it to be easy to implement? You could probably make a global LD_PRELOAD library that hooks into all open() CREAT calls and tags the inode's xattr with the program that created the file. You could use an attribute like, user.created_by.

Programs can use programs like 'touch' to create the files so you'd have to get meta into a chain of process ownership or something while exempting the user's shell.

Re: Dotfile madness

#87

Post by afiori »

gnomewascool wrote: post #51
kondor6c wrote: post #30

Earlier quoted context omitted.

Why not _shame_ openssh? Or vim? Or emacs? I would advise not calling for shame on any of these projects because they have a pattern to support that has been in place longer than the XDG standard has been in place. You can change gnupg's home dir, but it would break a lot of currently functional setups if it just moved.

> You can change gnupg's home dir, but it would break a lot of currently functional setups if it just moved. You can just change the default: if .gnupg exists, write everything to it. If not, write to $XDG_CONFIG_HOME/gnupg/ and $XDG_DATA_HOME/gnupg/ as appropriate (deciding how to carry out the split is not obvious, but can be done). I agree, though, that calling it "shaming" is neither justified, nor useful.

> (deciding how to carry out the split is not obvious, but can be done).

For this reason I like better the windows distinction, that (if I understand in correctly) distinguishes between machine-dependent files and machine independent files. for something like gnupg I would not really say what is data and what is configuration

Re: Dotfile madness

#88

Post by nine_k »

netsec_burn wrote: post #75
nine_k wrote: post #72

Earlier quoted context omitted.

Adding an interface to access the tag store won't be very hard. It would be harder to make it so that all the tag-oblivious programs, like mv or vi, to say nothing of rsync, would preserve the attributes when moving or modifying a file.

Sounds like you might need to hook rename() if you'd like to add that feature too, but I would still say it's straightforward.

The way most editors save a file is like this:

  f = open("the_file.new")
  write(f, new_contents);
  close(f);
  rename("the_file", "the_file~");
  rename("the_file.new", "the_file");
So the old file is never modified, it's renamed to the backup copy, and an entirely new file is created to take its place.

This has a number of advantages, but does not play well with any extended info the old file used to have, unless they are copied explicitly. And in a tagging-oblivious program, they won't be.

Re: Dotfile madness

#89

Post by xaduha »

seqizz wrote: post #49
xaduha wrote: post #10

> We are no longer in control of our home directories. I can axe my home folder and rebuild it with `nixos-rebuild switch`, it's pretty minimal.

Do you mean `home-manager switch` or is there a feature in nixos to touch home folders?

I just keep my home folder in /etc/username and use this construct:

(just an example, not actual)

environment.etc = {

    "qemu/bridge.conf".text = ''allow br0'';

    "username/.inputrc".text = ''
      \$include /etc/inputrc
      "\e[A": history-search-backward
      "\e[B": history-search-forward
      set show-all-if-ambiguous on
      set completion-ignore-case on
    '';
};

to write configs into /etc proper and my home folder.

Re: Dotfile madness

#90

Post by sandov »

fxfan wrote: post #16

To name and shame some culprits (the one's who have shame, I won't name java because I won't expect them to care) 1) Mozilla 2) Gnome 3) Gimp 4) GPG 5) Thunderbird (Why is there a sep directory and not under .mozilla) 6) mplayer I guess one reason why this occurs is that it's easier for to be carelessly cross-platform this way. Except you'd expect better from mozilla, specially because they store Windows stuff very w…

Speaking of Windows, their situation is worse. I remember installing a couple of games and suddenly my "My Documents" folder had "EA", "EA Games", "Electronic arts", "Rockstar games" folders.
Post reply on HN