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

Dotfile madness (2019)

0x46.net

Post reply on HN
Print view View original

161–170 of 185 posts

Re: Dotfile madness (2019)

#161

Post by pie_flavor »

matheusmoreira wrote: post #95
pie_flavor wrote: post #91

Earlier quoted context omitted.

The reason app developers think it's fine to dump them in $HOME is because Linux hides them. Those app developers do not bother hiding them on Windows. The specific functionality being used does not 'work just fine everywhere'. It is not the case that Linux functionality is How Computing Works with every deviation being 'out of the way', not even in a hypothetical world where Linux isn't the drastic minority of machi…

> Linux hides them Linux doesn't hide anything. It's POSIX and GNU programs that choose not show anything that starts with a dot by default. As far as Linux is concerned they're just normal files on the file system. It doesn't have to be that way. Personally I have my system configured so that all "hidden" files are shown because I hate the concept of hidden anything. I used to do this in Windows too. > The specific…

> Windows is the legacy proprietary system people only support because it gets them paid.

Windows is the system everyone actually uses - even developers!. I write software because I care about people using it.

> Why should the developers be shamed for not going of their way to support Windows conventions for Unix software?

Because it's wrong on Unix, and even wrong on Linux, and once you are doing the right thing on Linux it is no longer out of your way.

Re: Dotfile madness (2019)

#162

Post by rozab »

theamk wrote: post #5

> You will most likely want to create a default configuration file with sane and sensible default values the first time your program is executed. Please don't. Include the example configuration in your docs (/usr/share/PROG..) and mention it in the manual. Statistically user will have hundreds of apps installed but will only ever customize a small fraction them. So creating config unconditionally on first run is one…

I don't see much of a problem with them being initialized in $XDG_CONFIG_HOME/

Re: Dotfile madness (2019)

#163

Post by rozab »

delta_p_delta_x wrote: post #33

What I personally find more egregious are dotfiles and dot-dirs on Windows , created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a…

Windows is a lost cause anyway. Even Microsoft products (at a glance: IISExpress, Visual Studio, RDP, Powershell) happily dump their cruft in the Documents folder. I don't know where they imagine users should actually save the files they control.

Re: Dotfile madness (2019)

#164

Post by [deleted] »

hyperupcall wrote: post #7

I completely agree! That's why I created this site: https://xdgbasedirectoryspecification.com . We need some place where people can immediately understand the practical benefit, and the minimum ask of their users. Of course, it doesn't help just to complain about the issue in a void, so I've also submitted like 10 PRs and filed quite a few issues. Projects like pnpm and Poetry took note, and now they comply! Someone'…

[deleted]

Re: Dotfile madness (2019)

#165

Post by Beltalowda »

account42 wrote: post #154

> a Desktop directory. That last one has been created by Steam, which is quite unfortunate as I simply do not have a desktop or a desktop environment on my machine. Chrome and a number of other software insists on creating some of these directories (e.g. Downloads) too. However you can fix that by setting XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR in ${XDG_CONFIG_HOME}/user-dirs.dir to something else (e.g. your home direct…

I have tried everything under the sun, including user-dirs.dir:

    % cat ~/.config/user-dirs.dirs
    XDG_DESKTOP_DIR="$HOME"
    XDG_DOWNLOAD_DIR="$HOME"
Yet still:

    % ls -ld ~/Desktop
    drwxr-xr-x 2 mt mt 4096 Oct 22 18:04 /home/mt/Desktop/
Sometimes there's a ~/Downloads directory too. But not today.

I have no idea what keeps creating these. It's pretty annoying as I have a lot of intentionally short-named things in my ~ for easy shell usage, and it really sticks out.

inotify doesn't support reporting the PID of the process that triggered the event, but it seems fanotify does. Maybe I should set up a watcher for this.

Re: Dotfile madness (2019)

#166

Post by hyperupcall »

alwillis wrote: post #84
hyperupcall wrote: post #75

Earlier quoted context omitted.

Hmm, that's why I said inherent? Because as you mentioned there is a separate macOS directory structure and the system utilities don't follow the specification. Also, the specification is only written for Linux in mind, which is why I said "not inherent for macOS. Is there an exact phrasing you would prefer?

The short explanation is native GUI apps that use the macOS frameworks use the classic macOS directory structure. The classic Unix utilities and apps typically use $HOME on macOS, while their modern, often Rust-based replacements—WezTerm, Exa, fd, broot, Fish, etc.—use XDG. Vim uses ~/.vimrc while Neovim uses XDG.

I asked for an exact phrasing, not for an explanation, because I have already written exactly that under the "Should I do this on macOS?" heading...

Re: Dotfile madness (2019)

#167

Post by fiddlerwoaroof »

Macha wrote: post #160
fiddlerwoaroof wrote: post #158

Earlier quoted context omitted.

There’s always: rm -rf ~/.*/cache

Assumes the app uses cache as it's cache, rather than names like dlcontent, bananas_content, storage.sqlite, assets, meta, $TIMESTAMP.txt etc.

Well, I don’t mind standards, I just prefer all the files an app touches to be under a single root folder (that’s not just $HOME)

Re: Dotfile madness (2019)

#168

Post by klodolph »

codedokode wrote: post #89
klodolph wrote: post #87

Earlier quoted context omitted.

Hidden files on MacOS were used sparingly—the main instance of a hidden file is the file which stores an icon for a folder, if the folder has a custom icon. Hidden files are only hidden from the UI, they appear normally in the command line. The standard Unix folders (usr, var, etc) are also hidden—to be honest, this is a compromise because the Unix filesystem hierarchy sucks, but we are saddled with it for backwards…

Hiding thumbnails cache is bad because a user might believe that the USB drive is empty and doesn't have any confidential data but the thumbnails cache might still have them. There is no need to hide such files. Just display them as system files in Explorer. > The standard Unix folders (usr, var, etc) are also hidden Again there is no need to do it. Just move them to a directory named "System files".

You can’t move “var” to a “System files” folder. This would break programs which expect /var to be, well, at /var. Long ago on macOS, everything was in “System Folder”, and it worked fine, but macOS has since inherited a massive Unix legacy.

Thumbnail caches are not stored on USB drives, they’re stored somewhere else, away from your files.

Re: Dotfile madness (2019)

#169

Post by 8n4vidtmkvmk »

codedokode wrote: post #104
8n4vidtmkvmk wrote: post #83

Earlier quoted context omitted.

i just always list dotfiles for years now.. and my IDEs too. mostly a non issue.

And I have to enable showing them on every system I work with (and add -a to every ls command, and google which option enables incldues them in pattern expansion). That is annoying.

Well.. ya. I set up my aliases and then forget about it again. Globbing is mildly annoying but i think there's a dotglob option or something you can set

Re: Dotfile madness (2019)

#170

Post by 31b3r3t7 »

delta_p_delta_x wrote: post #66
matheusmoreira wrote: post #56

Earlier quoted context omitted.

I don't find it egregious at all. Nobody should go out of their way to integrate with Windows APIs when files work just fine everywhere.

> Nobody should go out of their way to integrate with Windows APIs int writeConfigFile(ConfigFile file) { #if defined(_WIN32) // Windows-specific function #elif defined(__linux__) // Linux-specific function #elif defined(__APPLE__) // macOS-specific function With modern C++, there's probably a way to do this in a nicer manner, and achieve runtime polymorphism with virtual functions or a lambda (function pointer) tabl…

No need for runtime polymorphism for this. The same binary won't be used in different operating systems. This is a classic example of misuse of C++ features just because they exist and a reason why I personally prefer programming in C. What I would do in a case like this is to have three source files each implementing the function for UNIX/Windows/Mac and the build system should take care of compiling the right one into the program depending on the OS.
Post reply on HN