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

91–100 of 185 posts

Re: Dotfile madness (2019)

#91

Post by pie_flavor »

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.

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 machines by an order of magnitude.

Re: Dotfile madness (2019)

#92

Post by pie_flavor »

matheusmoreira wrote: post #65
Spivak wrote: post #60

Earlier quoted context omitted.

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.

You're directly depending on platform-specific stuff the moment you look up the user directory, because it's not $HOME on Windows either.

There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.

Re: Dotfile madness (2019)

#94

Post by jl6 »

waste_monk wrote: post #90
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…

>What's the point of hiding some of the files in a directory from user? It only makes things more confusing. If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default? It's like training wheels on a bike. >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 empt…

> If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default? It's like training wheels on a bike.

This is really the problem with the home directory. It’s supposed to be the place where the user puts their files, but it’s also a place where applications put their files, usually without asking the user.

The battle is lost - the home directory territory should be ceded to applications and the user should have a separate space in which to manage their files.

This can sort of be achieved with the $XDG_CONFIG_HOME environment variable, but not all software respects it, so in practical terms it’s a lot easier just to leave $HOME to be the application config dumping ground.

Re: Dotfile madness (2019)

#95

Post by matheusmoreira »

pie_flavor wrote: post #91
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.

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 functionality being used does not 'work just fine everywhere'.

It kind of does. "Program reads configuration from a file" seems like a really basic thing that every operating system supports. There really is no need to directly depend on any Windows API stuff. Even worse would be suggesting the use of the registry.

> 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 machines by an order of magnitude.

And yet Windows is the system getting "half-baked ports of Unix-first software" here. Why should the developers be shamed for not going of their way to support Windows conventions for Unix software?

People develop software on and for the systems they actually care about. Windows is the legacy proprietary system people only support because it gets them paid. At least I hope someone got paid to port ssh to Windows because I sure wouldn't want to do it otherwise.

Re: Dotfile madness (2019)

#96

Post by toastal »

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…

If it's any consolation, games from Steam on Linux leak files all over the place on that OS too.

Right now the offenders in my $HOME not following $XDG are games, LibreWolf via Mozilla, Xmonad, GnuPG, and anything related to npm (with their maintainers closing any issued opened about support $XDG).

Re: Dotfile madness (2019)

#98

Post by leoh »

transfire wrote: post #86
throwamon wrote: post #21

Nix + home-manager. Boom.

Can you elaborate? How does that solve the problem?

nix home manager is very good.

The idea is that instead of creating a bunch of dotfiles and having to read a bunch of documentation, one declaratively states which features they want, say, for zsh or vim or git or xdg, etc; and then home-manager will create and manage them (typically they live in `$HOME/.config/whatever`).

https://github.com/nix-community/home-manager. Some examples on GitHub: https://github.com/search?q=filename%3Ahome.nix.

Re: Dotfile madness (2019)

#99

Post by ceving »

I do not understand the problem with "dot"-files. And I do not understand the benefit to have them in another directory. I think there are more important problems to solve in this world.

Re: Dotfile madness (2019)

#100

Post by matheusmoreira »

pie_flavor wrote: post #92
matheusmoreira wrote: post #65

Earlier quoted context omitted.

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.

You're directly depending on platform-specific stuff the moment you look up the user directory, because it's not $HOME on Windows either. There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.

It's just a different variable: USERPROFILE.

https://stackoverflow.com/a/42700844/512904

> being Linux but mangling it so it technically works on other platforms

Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it.

This is simple and works everywhere:

  char * home = getenv("USERPROFILE");
  if (home) {
      // Use home directory
  }
The answer demonstrating the Windows API way has the following code to accomplish the same thing:

  WCHAR profilePath[MAX_PATH];
  HRESULT result = SHGetFolderPathW(NULL, CSIDL_PROFILE, NULL, 0, profilePath);
  if (SUCCEEDED(result)) {
      // Use home directory
  }
Yeah, I seriously doubt open source developers want to deal with this Windows bullshit. I sure don't. Maybe if you're getting paid.
Post reply on HN