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

Rob Pike: the origin of dotfiles

plus.google.com

Post reply on HN
Print view View original

61–70 of 156 posts

Re: Rob Pike: the origin of dotfiles

#61

Post by jlgreco »

caf wrote: post #60
jlgreco wrote: 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'…

shrug, it seems to have all worked out pretty well.

Re: Rob Pike: the origin of dotfiles

#62

Post by DeepDuh »

Dylan16807 wrote: post #59
malkia wrote: post #24

Earlier quoted context omitted.

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

Re: Rob Pike: the origin of dotfiles

#64

Post by davvid »

moe wrote: post #16
keyist wrote: 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.

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 see no benefit.

How about consistency?

Re: Rob Pike: the origin of dotfiles

#65

Post by DeepDuh »

SoftwareMaven wrote: post #27
frossie wrote: post #19

Earlier quoted context omitted.

They are a natural segregator of novice and advanced users. If you have a limited level of interaction with the unix shell (remember than in the old days everyone in a science academic department used a Unix machine, even the dusty professors you kept in the back of the supplies cabinet), setting up their account and then making sure that they couldnt get into any trouble because they didn't know about 'ls -a' was ve…

OS X has a ~/Library directory that houses application settings and much else. It is hidden by default. There is no question there is a need to have a place that "plebeian users" can't access. IMO, dot-files and dot-directories are as good as anywhere.

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 need to do support on other systems I just ask myself why not every OS works this way. I can understand why Linux is the way it is and I like that too (for other reasons), but it at least shows why the Windows Registry is such a bad idea.

Re: Rob Pike: the origin of dotfiles

#66

Post by johnny22 »

tedunangst wrote: post #50
keyist wrote: 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…

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.

Re: Rob Pike: the origin of dotfiles

#67

Post by dfc »

moe wrote: post #16
keyist wrote: 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.

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?

Re: Rob Pike: the origin of dotfiles

#68

Post by strictfp »

malkia wrote: post #24
keyist wrote: 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.

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.

Re: Rob Pike: the origin of dotfiles

#69

Post by strictfp »

jlgreco wrote: post #61
caf wrote: post #60

Earlier quoted context omitted.

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'…

shrug , it seems to have all worked out pretty well.

But all programs must make exceptions for these entries. Imagine trying to add a third magic filename, '...', for the grandparent for example. You would have a lot of coding to do. Not really possible. It would have been better to mark the dirs as special somehow rather than having each program have the convention programmed in.

Re: Rob Pike: the origin of dotfiles

#70

Post by agumonkey »

raylu wrote: post #63
agumonkey wrote: post #39

Earlier quoted context omitted.

my de-obfuscation attempt: etc > e.t.c > edit to configure. the .rc suffix has a nice history btw

What's the history of that?

Legacy of the runcom shell that let's you record sequence of commands.

http://en.wikipedia.org/wiki/Run_commands

Post reply on HN