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

131–140 of 185 posts

Re: Dotfile madness (2019)

#131

Post by Milner08 »

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.

Well yeah.. because they are hidden files. They wouldn't be hidden files if the default wasn't to hide them...

Re: Dotfile madness (2019)

#132

Post by Already__Taken »

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.

hidden file extensions by default are to "save" users from renaming files and borking the extension. Later windows UX improved the renaming to help avoid selecting the extension.

file extensions are the mistake here really not them being hidden.

Re: Dotfile madness (2019)

#133

Post by TeMPOraL »

delta_p_delta_x wrote: post #38
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?

> on Windows There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`. In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.

There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory.

At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink().

--

[0] - https://news.ycombinator.com/item?id=33312712

Re: Dotfile madness (2019)

#134

Post by Y_Y »

_vufv wrote: post #114
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…

Also, idempotency of a tool is a desired property that tool devs often invest a lot of effort in maintaining. Initializing default config on the first run is a trivial way to break it. It's much better to just have a sane implicit default value for each setting when config is not present. Then you can list the default config in your docs or offer a CLI flag --print-default-config or --copy-default-config.

Creating a file if it doesn't already exist is idempotent.

Re: Dotfile madness (2019)

#135

Post by Macha »

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…

SteamApps/userdata, %APPDATA%/Publisher, %APPDATA/Developer, %LOCALAPPDATA%, the list goes on...

Re: Dotfile madness (2019)

#136

Post by Macha »

fiddlerwoaroof wrote: post #52
kragen wrote: post #49

Earlier quoted context omitted.

I find it useful; I might want to version-control .config but definitely not .cache. And if the program is broken I might blow away .cache but not .config.

That still works if it’s `~/.foo/cache`

    rm -r ~/.foo/cache ~/bar/cache ~/baz/data/app/cache [20 more apps..]
is less ergonomic than

    rm -r ~/.cache/\*

Re: Dotfile madness (2019)

#137

Post by annowiki »

codedokode wrote: post #80
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 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?

Re: Dotfile madness (2019)

#138

Post by [deleted] »

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.

[deleted]

Re: Dotfile madness (2019)

#139

Post by donatj »

Already__Taken wrote: post #132
delta_p_delta_x wrote: post #126

Earlier quoted context omitted.

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.

hidden file extensions by default are to "save" users from renaming files and borking the extension. Later windows UX improved the renaming to help avoid selecting the extension. file extensions are the mistake here really not them being hidden.

Executability based on extension combined with hidden extensions is imho one of Windows biggest mistakes. Make an exe, give it the icon of a word document - no way for a layperson to know it’s a trick.

Re: Dotfile madness (2019)

#140

Post by rollcat »

klodolph wrote: post #87
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…

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…

For people out there on macOS, you can press Cmd-Shift-dot in Finder to toggle displaying any hidden files (including the standard UNIX hierarchy at /).

By the way, I'm pondering setting my XDG_*_HOME vars on Linux/BSD to use the macOS paths like ~/Library, just to see if the standard is actually being followed.

Post reply on HN