5 ms·
I still think it is a mistake which you may be repeating by conflating two concepts: - The location of a file - Standard visibility of the file If you hide s
by ablob 4y ago
I still think it is a mistake which you may be repeating by conflating two concepts:
- The location of a file
- Standard visibility of the file
If you hide something (like a folder) temporarily and refer to it through a script, you have to go to the script and change it once you decide that you don't want the folder hidden anymore.
The script is now coupled to not only the location of the resource, but also its visibility.
There is no reason to conflate the two concepts. Git folders can still be hidden by default without requiring adaptation to path names.
I'd argue, what you're loving about dotfiles is not the presence of the dot, but the concept of visibility levels on files.
- account42 4y agoBut combining these concepts is useful - with a .dot you know based on the name alone if it is hidden or not. If there was a hidden flag then whether or not a file is hidden is itself hidden. E.g. you could have something referring to a file by any name which your file browser / ls does not show and but the file is still there and will be loaded - that's unnecessarily surprising.
- ablob 4y agoGiven that we live on a timeline it is useful for sure. Having a dotfile automatically marked as hidden for example is a useful combination that keeps learned traditions when preferred. > that's unnecessarily surprising. I found it unnecessarily surprising that dotfiles werent shown when I got started with unix-like systems. I consider "surprise" to be a weak argument in this case, especially since we do have things that refer to a file that both the file browser and ls do not show (but which are still loaded since opendir and readdir do not care about the dot). Whether or not a file with a dot at the beginning is shown or not is nothing but arbitrary convention. I'd like my convention to not care about the file path to decide "does ls or the file browser show it", as that is how I prefer different concepts in general: decoupled. However, I do accept surprise as an argument against hidden files at all (including dotfiles).
- PeterWhittaker 4y agoI understand what you mean, and would argue that the . prefix is a simple - and widely accepted - way of achieving this, as someone noted elsewhere, convention over configuration. The only way to get truly hidden folders is to agree on an approach and have it adopted everywhere. Someone’s git-aware GUI app might know to hide git, but as a CLI guy, should I have ls modified? Or find? Or my shell (if so, which one)? The . prefix hides things most users don’t need to see (. and ..) and allows many other things to be usefully hidden in a convenient and consistent manner. To rephrase my original comment and integrate the crux of yours, Pike is wrong to call this a mistake, because it accidentally gave us a really useful capability that has been widely integrated into most/all of our tools, while allowing us to work around it simply and effectively when we want or need to.
- em-bee 4y agofor an alternative that would not have been to hard to implement they could have used the permission bits for hidden files. it would take another bit, but i think there were some spare.
- sophacles 4y agoAbusing permission bits would be the same form of problem as abusing names, however permissions are part of a larger bitfield `st_mode` that contains other useful info like file type (e.g. symlink, fifo, etc), which would make sense to extend to include "visible" or whatnot. Sorry, not trying to knock your idea, just had to let my inner pedant out a bit.