3 ms·

I 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

I 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 ago
for 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 ago
  Abusing 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.
  - Evidlo 4y ago
    Then you have problems with file system portability like you get with permissions.
    - sophacles 4y ago
      That sounds like a standards problem more than something wrong with the idea itself.
    - wongarsu 4y ago
      Dotfiles aren't universal either: Windows doesn't hide dotfiles and instead uses a file attribute to mark hidden files. Whatever you do will have portability concerns.
      - PeterWhittaker 4y ago
        I would never argue that is universal, but just confine myself to the UNIX/Linux world. Were we to argue for universality, we’d be lost within a sea of /, \, -, /, //, \\, drive prefixes, and a few other things. Within the UNIX/Linux world, though, it’s a remarkably useful and effective convention, implemented and respected with considerable consistency. (Windows hidden files really aren’t, not once one drops to a CLI, and even then, it depends on the CLI. I’m not offering that as a criticism, but more of a caution of how difficult it is to get something like this to work. Extended attributes and even basic permissions have their twists and difficulties, even within a platform or platform family, let alone cross platform.)
        em-bee 4y ago
        the primary difficulty is to implement a mechanism to carry those attributes in the first place. that's a problem we already have. once that mechanism is there, we can add whatever attributes that we want. this should have been a concern from the beginning. instead of the hackish workaround of encoding attributes into the filename. they should never have been there. even file-type extensions should have been a separate field of some sort right from the start.
        PeterWhittaker 4y ago
        Like they were in Mac OS back in the day, when files had resource forks and data forks? Or like magic numbers in UNIX/Linux? The whole extension thing was odd from the beginning. When I first used Windows, after years of UNIX, extensions puzzled me. On UNIX, they told ME something, the OS and apps didn’t need them (/etc/magic did the trick), but here they were on Windows being given semantic value. Ironically, now that I think about it, I found Windows extensions odd for the same reason that some find hiding dotfiles on UNIX/Linux odd. This makes me chuckle ruefully.
  - em-bee 4y ago
    yes, thank you. if i had taken a few more minutes to look at the actual data structures, i would have come to the same conclusion. today i would probably use extended attributes, since they are a lot more flexible

em-bee 4y ago

for 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 ago
Abusing 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.
- Evidlo 4y ago
  Then you have problems with file system portability like you get with permissions.
  - sophacles 4y ago
    That sounds like a standards problem more than something wrong with the idea itself.
  - wongarsu 4y ago
    Dotfiles aren't universal either: Windows doesn't hide dotfiles and instead uses a file attribute to mark hidden files. Whatever you do will have portability concerns.
    - PeterWhittaker 4y ago
      I would never argue that is universal, but just confine myself to the UNIX/Linux world. Were we to argue for universality, we’d be lost within a sea of /, \, -, /, //, \\, drive prefixes, and a few other things. Within the UNIX/Linux world, though, it’s a remarkably useful and effective convention, implemented and respected with considerable consistency. (Windows hidden files really aren’t, not once one drops to a CLI, and even then, it depends on the CLI. I’m not offering that as a criticism, but more of a caution of how difficult it is to get something like this to work. Extended attributes and even basic permissions have their twists and difficulties, even within a platform or platform family, let alone cross platform.)
      - em-bee 4y ago
        the primary difficulty is to implement a mechanism to carry those attributes in the first place. that's a problem we already have. once that mechanism is there, we can add whatever attributes that we want. this should have been a concern from the beginning. instead of the hackish workaround of encoding attributes into the filename. they should never have been there. even file-type extensions should have been a separate field of some sort right from the start.
        PeterWhittaker 4y ago
        Like they were in Mac OS back in the day, when files had resource forks and data forks? Or like magic numbers in UNIX/Linux? The whole extension thing was odd from the beginning. When I first used Windows, after years of UNIX, extensions puzzled me. On UNIX, they told ME something, the OS and apps didn’t need them (/etc/magic did the trick), but here they were on Windows being given semantic value. Ironically, now that I think about it, I found Windows extensions odd for the same reason that some find hiding dotfiles on UNIX/Linux odd. This makes me chuckle ruefully.
- em-bee 4y ago
  yes, thank you. if i had taken a few more minutes to look at the actual data structures, i would have come to the same conclusion. today i would probably use extended attributes, since they are a lot more flexible