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

141–150 of 185 posts

Re: Dotfile madness (2019)

#141

Post by blueflow »

hyperupcall wrote: post #9
bee_rider wrote: post #3

Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

strongly disagree - as of 2022, more apps follow the XDG Base Directory Specification than not - in fact, by a wide margin. So by "doing dirty" in your users home directory, you're going against the grain of the ecosystem. It doesn't seem like you understand much about the specification? I'd recommend reading it, or at least a short summary I've made available here: https://xdgbasedirectoryspecification.com/

"Everybody else does it" is not an argument.

Re: Dotfile madness (2019)

#142

Post by rollcat »

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…

> #elif defined(__linux__)

I felt a great disturbance in the source, as if hundreds of BSD users suddenly cried out in terror and were suddenly silenced.

Re: Dotfile madness (2019)

#143

Post by blueflow »

scintill76 wrote: post #50
bee_rider wrote: post #3

Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

> XDG is just some group vs > the de-facto community standard Feels like you’re just selectively defining “community” to exclude XDG. Maybe there’s a good reason, but you haven’t really described it. Whoever defined $HOME as a place to stick configuration files was also “just some group.”

Freedesktop (new name for XDG) is not the community. They are some people with a bad reputation when it comes to software quality and maintenance.

Re: Dotfile madness (2019)

#144

Post by rollcat »

ChrisSD wrote: post #61
CGamesPlay wrote: post #35

Earlier quoted context omitted.

Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?

The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent. E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands…

> E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory.

Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility.

[1]: https://web.archive.org/web/20220824070659/https://9p.io/sys...

[2]: https://golang.bg/pkg/path/#Clean

Re: Dotfile madness (2019)

#146

Post by nyuszika7h »

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 agree, at least if there is nothing that absolutely has to be specified for the program to work.

Re: Dotfile madness (2019)

#147

Post by jstanley »

annowiki wrote: post #137
codedokode wrote: post #80

Earlier quoted context omitted.

I think "hidden" files are a bad idea. What's the point of hiding some of the files in a directory from user? It only makes things more confusing. For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files. Even worse, imagine if all files on an USB drive are marked as hidden. You see that the driv…

When I run ls I don't want to see all the configuration files. Just my files. I think that's the point of hidden files. > One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. How likely is it that someone is going to want to edit a .env file and not know how to view hidden files?

> When I run ls I don't want to see all the configuration files. Just my files.

Well then configuration files can simply not be in the same directory as your files. Easy fix.

Re: Dotfile madness (2019)

#148

Post by rogual »

delta_p_delta_x wrote: post #51
deburo wrote: post #41

Earlier quoted context omitted.

On Windows anyway, the root of the user profile is already filled with garbage directories, and so a few more dot-dirs and files feel par for the course. The advantage is that accessing your root dir is easier than typing out %appdata% in File Explorer.

One could say the same for ~ on Linux. 'It's already bad' isn't an excuse for sloppy programming. Software should ideally adhere to OS norms. Better still, software shouldn't be opaque about where global/user-specific cache/config data is stored, and should prompt users to choose (or set sane defaults, again adhering to OS norms). IMO the video game industry is a big offender of home-folder pollution, with saves and…

When making games, I have them store their config in %APPDATA% on Windows, although I do see the downside if there's a bug and I want to direct a customer to send me a log file that was saved there or just generally delete or move files around in there. It's not as familiar and safe-feeling for a nontechnical user to navigate to %APPDATA% is it is to just look in their Documents.

Re: Dotfile madness (2019)

#149

Post by maicro »

delta_p_delta_x wrote: post #126
codedokode wrote: post #80

Earlier quoted context omitted.

I think "hidden" files are a bad idea. What's the point of hiding some of the files in a directory from user? It only makes things more confusing. For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files. Even worse, imagine if all files on an USB drive are marked as hidden. You see that the driv…

Personally, I think hidden files are OK, but we have lousy defaults, regardless of OS. By default, Explorer hides hidden files (and goes one step further and doesn't display file extensions: why ???), so do Finder, Dolphin, Nautilus, and even `ls` by default.

"Show hidden files" and "show extensions for known file types" are two folder options I enable on any Windows system I touch / within a few minutes of installation. I'll take a bit of extra visual clutter if it means I can actually see what all is in a folder, vs. just assuming I know.

Re: Dotfile madness (2019)

#150

Post by chimprich »

fergie wrote: post #106

Surely config goes in $HOME and thats that? I dont see how specifying another directory makes life any easier.

The article lists several advantages.

If you don't like having a separate directory for config files you can set your XDG variables appropriately.

Post reply on HN