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

61–70 of 185 posts

Re: Dotfile madness (2019)

#61

Post by ChrisSD »

CGamesPlay wrote: post #35
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…

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.

Re: Dotfile madness (2019)

#62

Post by anonyme-honteux »

Does anyone know of any small library in JavaScript/python/go/rust or any language that people use to write CLI apps that makes it trivially easy to implement this spec, even better if it also supports similar conventions for MacOS and Windows?

Re: Dotfile madness (2019)

#63

Post by frizlab »

nathanaldensr wrote: post #18

I think the real culprit here are operating systems and file systems, not programmers (of end-user applications). File systems were designed during an era where semantic meaning was just not important; all file systems cared about (and still care about) are directories and files. The whole paradigm should've been abandoned long ago for something much cleaner.

Like what?

Re: Dotfile madness (2019)

#64

Post by richardwhiuk »

anonyme-honteux wrote: post #62

Does anyone know of any small library in JavaScript/python/go/rust or any language that people use to write CLI apps that makes it trivially easy to implement this spec, even better if it also supports similar conventions for MacOS and Windows?

https://docs.rs/dirs/latest/dirs/index.html

Re: Dotfile madness (2019)

#65

Post by matheusmoreira »

Spivak wrote: post #60
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.

It’s basically the same as looking up $XDG_CONFIG_HOME on GNU/Linux.

That's just an environment variable while this ShGetKnownFolderPath thing is a Win32 API function. People should avoid directly depending on that stuff as much as possible.

People aren't obligated to "comply" with the XDG specification either. It's not a bug to just use $HOME.

Re: Dotfile madness (2019)

#66

Post by delta_p_delta_x »

matheusmoreira wrote: post #56
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…

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) table.

As another sibling commenter wrote, .NET already has a platform-agnostic function to write to a `user program data` folder that nicely maps to the platform-specific directories. Other GC languages (Java, Go, etc) likely have similar abstractions.

As for scripting... A cross-platform project with scripts that also targets Windows should (in my opinion) have PowerShell `.ps1` scripts accompanying any `.sh` scripts. Better still, scripting should be done in a language that's truly platform-agnostic, like Python.

Re: Dotfile madness (2019)

#67

Post by fiddlerwoaroof »

jsmeaton wrote: post #55
fiddlerwoaroof wrote: post #42

Earlier quoted context omitted.

I personally hate the XDG directories. It’s annoying for different part of an application’s data to be split between `~/.config`, `~/.Cache`, etc. Rather than for all the data for the `foo` program to be in a file named something like `~/.foo*`

Asked out of ignorance, but do the envvars not allow one to easily co-locate data/config/cache by setting them all to the same value?

Not in a way that would be useful here, I think: I prefer ~/.firefox/cache to ~/.cache/firefox and this requires the variables being unique per program (although, you could probably wrap each program with a script that sets the relevant environment variables to achieve this effect)

Re: Dotfile madness (2019)

#68

Post by matheusmoreira »

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…

> 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) table.

You proved my point. Creating an #ifdef mess with polymorphism, virtual methods and indirection is the very definition of going out of one's way to support something that really doesn't need any support.

Re: Dotfile madness (2019)

#69

Post by delta_p_delta_x »

matheusmoreira wrote: post #68
delta_p_delta_x wrote: post #66

Earlier quoted context omitted.

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

> 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) table. You proved my point. Creating an #ifdef mess with polymorphism, virtual methods and indirection is the very definition of going out of one's way to support something that really doesn't need any support.

If a developer writing in C/C++ is targeting Windows, then bringing in `` (and associated headers) is almost guaranteed, especially if said developer wants to work with native APIs (unless said program will rely on MinGW/Cygwin/Msys2, which are arguably worse, since they drag in an entire Linux directory tree per application).

This is just part of the cost of developing cross-platform, and I'm sorry, but to me, dismissing this as 'going out of one's way' is just being sloppy.

Re: Dotfile madness (2019)

#70

Post by guilherme-puida »

kragen wrote: post #48
hyperupcall wrote: post #9

Earlier quoted context omitted.

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/

My home directory has dotfiles for aspell, bash, bzr, cargo, Clojure, CPAN, CVS, Darcs, D-BUS, Dillo, DOSBox, DOSEmu, Emacs, Eclipse, Emacs, ESD, FLTK, fontconfig, FontForge, GForth, GHC, the GIMP, Git, GnuPG, Gnuplot, Guix, IceWM, Idle, Java, John the Ripper, Jython, Links2, MilkyTracker, Mozilla (Firefox), MPlayer, Nethack, Octave, Racket, R, Skeinforge, Slic3r, SSH, SQLite, Subversion, Units, Vim, W3M, WINE, X-Win…

> it would not improve my user experience for those "apps" to look for my configuration file in two different places

Some of those already do, though. At least Vim and Emacs do, and I personally have zsh in .config as well.

Post reply on HN