Hacker News Reader

Comment by jenadine | Hacker News Reader

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache

But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

View on HN

Somebody should tell this to go people. They just create me a non-hidden directory `~/go`

  export GOPATH=~/Projects/go

Has been like this since forever.

Being like that for a long time is not a justification for terrible defaults.

That is a better default than a hidden directory. It is obvious and so you can set GOPATH

Also works better on Windows where .path is not hidden

Also it seems Rob Pike one of the creators of Go and involved with early UNIX thinks that . making hidden files was a mistake. Quote via XahLee http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_... - original was Google+ so not existing now.

I hate it when I forget to show hidden files on mac.

They had a kb shortcut for it

They still do: Shift-Command-period toggles hidden files visibility.

And then you have a french layout where it's impossible to fire this keyboard shortcut.

Oy. That surprised me. I am quite familiar with the notion of common keyboard shortcut that I can't get on my Norwegian keyboard. Command-(left/right) square bracket is very common, but at least that is usually associated with a menu item so I can assign a different shortcut. But now I learned that on a French keyboard, period is shift-semicolon!? Which makes me wonder: Do the French use the semicolon more often than the period? Oh well, once in a while it sucks not to be American. ;-)

Sure, hidden folders are a mistake, but less of a mistake than not adhering to standardized folder structures and just littering in people's home folders.

> But they don't seem to care

While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.

You're right. I apologize. The fact that there was a PR actually shows that some people care.

There are 200 thumbs up? And a lot of those are rust people who care.

In my experience, the usual reason for a project not using the XDG Base Dir spec is because somebody on the project simply doesn't like it, particularly XDG_CONFIG_HOME defaulting to $HOME/.config. Resistance to the XDG Base Dir spec really does seem to be rooted in personal preference, I've never seen an objection to it on any technical basis.

The best arguments against it that I've seen are "many other projects don't use this spec, so why should we?" (e.g. our project should be the last to adopt it.. but why?) and arguments along the lines of "XDG_BIN_HOME isn't in the spec, therefore we shouldn't use XDG_CONFIG_HOME", which just seems like a lame excuse.

XDG_BIN_HOME is crucial, without it, not supporting the spec seems like the right call. Better to deal with the status quo until updates happen than to get stuck in bikeshed hell.

You're letting perfect be the enemy of good. Other projects, like python, use $HOME/.local/bin as the spec suggests and it works out fine in virtually all cases.

> "User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place."

> "Since $HOME might be shared between systems of different achitectures, installing compiled binaries to $HOME/.local/bin could cause problems when used on systems of differing architectures. This is often not a problem, but the fact that $HOME becomes partially achitecture-specific if compiled binaries are placed in it should be kept in mind."

https://specifications.freedesktop.org/basedir-spec/basedir-...

The omission of XDG_BIN_HOME is regrettable, but not a showstopping problem unless you want it to be a problem. W.r.t. a single $HOME across multiple architectures, "not often" a problem is an overstatement of the problem; the number of people using a single $HOME across multiple architectures is a rounding error (I say that as somebody who once did so) and such people are already accustomed to dealing with the difficulties that arise from it. They're going to hoist themselves with Go and Rust's defaults anyway.

Rust postponed this feature in the RFC process. https://github.com/rust-lang/rfcs/pull/1615

So it's been through some official channels.

You can also use the environment file linked in that blog post to tell Rust to follow the XDG standard. Not perfect because it is not the default behaviour but it is doable.

At least for rust applications of your own, you can use the library https://github.com/dirs-dev/directories-rs to follow XDG on Linux as well as platform conventions on Mac and Windows.

I put it in another comment, but if you are Rusting on Linux, you can use boxxy to fix bad behaving applications.

https://github.com/queer/boxxy

Reply on news.ycombinator.com