Golang puts shit specifically in $HOME/go. Not even .go. Just plain go.
Why is it so difficult to follow industry standards
this post was submitted on 14 Jul 2024
285 points (94.7% liked)
Linux
48023 readers
988 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
That's what happens when you don't set $GOPATH I think
That doesn't make it better.
It makes it insofar better to me that you have the option to change it. You can't change Mozilla programs to use anything but .mozilla (apart from modifying the source code of course) so for me seeing the folder is at least a way of telling me that the variable is unset.
The better question is which folder is suited the best to store the stuff that goes into $GOPATH
Just because something is worse, doesn't make the other thing good. A sane and standard default, as others have mentioned, is a small bar to meet.
Of course, but that's not the point. There should be a sane default, and there isn't one
Go pisses me off with that. I separate projects the way I want but go wants every project written in go in one big directory?
load more comments
(3 replies)
load more comments
(9 replies)
Shout out to xdg-ninja - it'll find files that are in your home and suggest how to configure the app to use XDG instead. https://github.com/b3nj5m1n/xdg-ninja
Strange that some apps allow configuring it rather than just doing it automatically...
load more comments
(1 replies)
load more comments
(2 replies)
I wish they used them all, especially XDG_CACHE_HOME which can become pretty big pretty fast.
And i wish there was a separate XDG_LOG_HOME or $HOME/.local/log, with logrotate preconfigured to look there.
load more comments
(1 replies)
100% agree and I also despise devs who do this on windows, instead of using %appdata% they’re using c:\users\username\.myappisimportantandtotallydeservesthisdir
I have to use a separate Documents folder for my actual documents lol
load more comments
(4 replies)
I didn't know about this (and thankfully, haven't written anything public). I've been trying to fix an install script for an OSS project that doesn't work on immutable distros, and using the XDG Base Directory specs might just be the panacea I was looking for!
Where did i read this... basically, the .file being hidden being a bug in the early unix filesystem, which got misused to hide configuration files.
Offenders despite XDG-variables set and with no workaround:
- .android: hardcoded in adb and i guess something in mtp too
- .pki: some tool/library Firefox and Chromium sometimes use.
- .steam: yes, that
Here is a more concise way to achieve the same thing:
ls -ACd ~/.??*/ | sed -e "s#$HOME/##g"
I think that can be boiled down to only cd; echo .*/
Maybe throw a ;cd - on the end if the change of directory is unwanted.
load more comments
(1 replies)
load more comments
(1 replies)
My fellow FOSS users, patches are welcome.
there's no place like 127.0.0.1
there's no place like XDG_CONFIG_HOME.
vim now has an option to put the .vim folder in ~/.config; though I'm not sure if the default plugin/package & syntax folders can be set under ~/.local/share.
load more comments
(1 replies)
BRB, putting in a PR to make /etc mode 1777 by default.
YOU'RE NOT MY MOM I'LL DO WHAT I WANT
view more: next ›