Live data from Hacker News

Rob Pike: the origin of dotfiles

plus.google.com

121–130 of 156 posts

Re: Rob Pike: the origin of dotfiles

#121
post #75

I hate having dotfiles in ~/ for the same reason why I hate "My Documents" in Windows: because it's supposed to be my space that I organize, not a generic dumping ground for your config files, brand-named folders, or other nonessential garbage. I want my space to be mine . Keep your app's stuff out of there!

But My Documents is one level below your homedir.

Your homedir equivalent on windows (since Windws XP) is /Documents and Settings/username, or the modern shortened equivalent. That has subdirectories for documents and application settings. Apps that put config data in My Documents are using behaviour dating back to Windows 95.

It's the same on Mac OS - /Users/username has a Documents subdirectory. Mac spps tend to be better-behaved, but a few manage to pollute the Documents directory. On Linux you may roll your own or use a ~/Documents directory created by your desktop environment. The fact is your homedir is the home of pretty much anything that is user-specific, and you either need to collect all the config data into some sort of config directory, or do your own organising in a subdirectory, or both.

Re: Rob Pike: the origin of dotfiles

#122
post #24
post #2

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.

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.

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).

Re: Rob Pike: the origin of dotfiles

#123
post #23
post #16

Earlier quoted context omitted.

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.

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…

> 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.

Re: Rob Pike: the origin of dotfiles

#124
post #123
post #23

Earlier quoted context omitted.

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…

> 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.

Re: Rob Pike: the origin of dotfiles

#125
post #82
post #65

Earlier quoted context omitted.

OSX, because of its big corporate watchdog, and the separation of the 'GUI' layer and the unix layer, has the cleanest directory structure by far IMO. Most of the times you don't even need a manpage or google to find out how to repair a misbehaving application - just delete its plist in ~/Library/Preferences, possibly also its ../ApplicationSupport directory. The OSX defaults system is so well designed, every time I…

had the cleanest directory structure until 10.8: ~/Library/Containers/com.apple.Preview/Data/Library/Application Support/Preview ~/Library/Containers/com.apple.Preview/Data/Library/Preferences/com.apple.Preview.plist

Isn't this change because of app sandboxing?

Re: Rob Pike: the origin of dotfiles

#126
post #93
post #44

I really like it that G+ is becoming a "lightweight blogging" platform. There are too many of these around, and folding them into a "social network" seems like a good idea. I wish they would add more features that would make this easier, though, since in general I think it's in everyone's interest and will pull more traffic to the site.

I'd like it if I didn't need a Google account to read anything on it.

Yeah, it's pretty lame that if I'm signed into Google but don't want to accept G+'s real name policy, I can't read otherwise public posts.

Re: Rob Pike: the origin of dotfiles

#127
post #67
post #16

Earlier quoted context omitted.

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.

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

Re: Rob Pike: the origin of dotfiles

#128
post #20

Earlier quoted context omitted.

I would like to hear a good argument for why hidden files and folders are a good thing. They keep users from monkeying with stuff until they are smart enough to find the hidden files.

*knowledgable enough

No, 'smart' is the right word.

Re: Rob Pike: the origin of dotfiles

#129
post #60
post #57

Earlier quoted context omitted.

Why? Seems like a brilliantly simple quick solution that would be rather easy to roll back in the future and lacks any real downsides besides being a tad weird.

Because it was creating real directory entries that caused "." and ".." to be visible to userspace programs reading a directory, which then led to the hack in "ls" to hide them, which is where the article picks up. It also isn't that easy to roll back once userspace programs start to rely on it - for example, the assumption that the number of files in a directory is equal to st_nlink - 2 is now so widespread that it'…

Except, like, in the root.

Re: Rob Pike: the origin of dotfiles

#130

Earlier quoted context omitted.

Is there a preferred standard for using the SD/external storage on Android?

http://www.reddit.com/r/Android/comments/t3x0p/randroid_lets... > I do find it odd that so many apps have this problem. It's trivially easy to get the proper location. Just call getExternalFilesDir() . Deletion at uninstall happens automatically. In fact, it's the ONLY way to make sure those files are deleted when you uninstall, because you can't run code at uninstallation.

Probably because it came in fairly late (Froyo, I think).
Post reply on HN