Rob Pike: the origin of dotfiles • Hacker News Board

Re: Rob Pike: the origin of dotfiles

#51

Post by aroman » Fri, Aug 03, 2012, 4:56 AM UTC

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.

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?

Re: Rob Pike: the origin of dotfiles

#52

Post by njharman » Fri, Aug 03, 2012, 4:59 AM UTC

seanalltogether wrote: post #21

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…

I wonder if that is a good solution for separating novices and pros though? For me, hidden files and folders only help to reinforce the confusion people have about computers. It's one thing to provide a folder to a user with a lock or shield on it, it's another to completely hide it from them.

They aren't hidden, completely or otherwise. Dotfiles are locked, '-a' is the key.

Re: Rob Pike: the origin of dotfiles

#53

Post by mseepgood » Fri, Aug 03, 2012, 5:05 AM UTC

He also writes why the dd command is so horrible: "dd is horrible on purpose. It's a joke about OS/360 JCL. But today it's an internationally standardized joke. I guess that says it all."

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

Re: Rob Pike: the origin of dotfiles

#54

Post by masklinn » Fri, Aug 03, 2012, 5:06 AM UTC

ricardobeat wrote: post #32

angusgr wrote: post #31

Earlier quoted context omitted.

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

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

Re: Rob Pike: the origin of dotfiles

#55

Post by jlgreco » Fri, Aug 03, 2012, 5:08 AM UTC

darkarmani wrote: post #43

moe wrote: 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.

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

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

So.. no.

Re: Rob Pike: the origin of dotfiles

#56

Post by ricardobeat » Fri, Aug 03, 2012, 5:14 AM UTC

masklinn wrote: post #54

ricardobeat wrote: post #32

Earlier quoted context omitted.

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

Re: Rob Pike: the origin of dotfiles

#57

Post by jlgreco » Fri, Aug 03, 2012, 5:15 AM UTC

caf wrote: post #45

The fact that "." and ".." were allocated actual directory entries and were returned when reading the directory, rather than just being handled by the kernel when parsing pathnames seems like the original sin of expediency here.

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.

Re: Rob Pike: the origin of dotfiles

#58

Post by jlgreco » Fri, Aug 03, 2012, 5:20 AM UTC

joe_the_user wrote: post #46

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…

Lol, They are a natural segregator of novice and advanced users. Yeah, they let that guy in the computer lab who "really knows Unix" show his stuff. I remember encountering these dot-whatever files back in the day, how changing all the idiotic terminal settings depended on them and how remembering their names or interpreting their values was nearly impossible, and how the cool geeks of the lab had about six seconds o…

99% of all dotfiles that I am aware of are named for the programs that they are for. Bash's start with .bash, Zsh's with .zsh, mplayer is .mplayer, Vim's start with .vim, elinks is .elinks, screen's start with .screen, Dropbox is .dropbox... I'm not sure how any of that is hard to remember. The only real barrier to entry here is knowing that you should look for them in the first place (well, that and the new XDG crap..).

What is actually in them is an entirely different matter.

Re: Rob Pike: the origin of dotfiles

#59

Post by Dylan16807 » Fri, Aug 03, 2012, 5:26 AM UTC

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.

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

Re: Rob Pike: the origin of dotfiles

#60

Post by caf » Fri, Aug 03, 2012, 5:28 AM UTC

jlgreco wrote: post #57

caf wrote: post #45

The fact that "." and ".." were allocated actual directory entries and were returned when reading the directory, rather than just being handled by the kernel when parsing pathnames seems like the original sin of expediency here.

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's part of the UNIX API.