4 ms·

> The Unix people did have a good point about everything being a file. Yes and no. While it simplifies things to an extent, it's also confusing, especially wit

> The Unix people did have a good point about everything being a file. Yes and no. While it simplifies things to an extent, it's also confusing, especially with extension-less files. Example: Tell me, is this a file or directory? ~/hn/today-posts It could be a file that curls todays posts, or it could be a folder (directory) that contains them.

sva_ 4y ago
The terminal emulator may change the color of the prompt, for example.
yegle 4y ago
How would adding an extension solve the issue? E.g. is this a file, a device file, or a symlink? /dev/readme.dev To know what this is, a `stat(2)` is required.
crabbone 4y ago
Valid complaint, but maybe not such a great reason. It gets worse when you deal with sysfs or procfs and similar. It all becomes obscure magic, like what values can be written into what file, why some files aren't readable, or the contents of files being just a bunch of numbers which you have no way of interpreting. Another problem is that there's way too many of different file types and they aren't organized into any kind of hierarchy or any other meaningful order. This makes tools like rsync extremely complicated, with loads of footguns and still not solving the problem well. It feels especially bitter because in exceeding majority of cases you don't want tools like rsync to deal with named FIFO or device files or sockets etc. but you get accidentally but painfully bitten by them every now and then.
drdaeman 4y ago
> Example: Tell me, is this a file or directory? A directory is a file (and IIRC e.g. Plan 9 decided they should be readable just like normal files and there shouldn't be any special readdir syscalls). You can see its attributes to figure out the rest. If not for strong Linux limitations (because of alleged hardlink knot-tying problem) and belief that it just cannot be both, transparent archive access through a filesystem would be a thing. As well as metadata access (`play ./file.mp3` vs `edit ./file.mp3/id3v2`). People of the past seemed to have paid great attention to interoperability and effort to make common interfaces; folks of the modern age ('00s and later) love unique and completely incompatible solutions to the same problem.
- christophilus 4y ago
  Neat. I’ve often wished I could cat a directory or ls a file. Plan9 sounds like something I would have enjoyed using.
  - enriquto 4y ago
    > I’ve often wished I could cat a directory This was possible in the beginning. But then came the moral police and deprived us of this freedom, because they deemed it to be "confusing". See, for example, The Unix Programming Environment, by Kernighan and Pike, page 51 [0]: Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. (...) The time has come to look at the bytes in a directory: $ od -cb . [0] https://archive.org/details/UnixProgrammingEnviornment/page/n61/mode/2up https://archive.org/details/UnixProgrammingEnviornment/page/...
dredmorbius 4y ago
'ls -l' will tell you the basic information of a given listing, including whether it's a normal file, directory, symlink, block device, named pipe, etc. stat(1) will provide additional information on a file. file(1) will not only distinguish between filesystem=level distinctions, but will make a remarkably good guess as to what the file contents of a normal file are, based on magic(5).

sva_ 4y ago

The terminal emulator may change the color of the prompt, for example.

yegle 4y ago

How would adding an extension solve the issue? E.g. is this a file, a device file, or a symlink? /dev/readme.dev To know what this is, a `stat(2)` is required.

crabbone 4y ago

Valid complaint, but maybe not such a great reason. It gets worse when you deal with sysfs or procfs and similar. It all becomes obscure magic, like what values can be written into what file, why some files aren't readable, or the contents of files being just a bunch of numbers which you have no way of interpreting. Another problem is that there's way too many of different file types and they aren't organized into any kind of hierarchy or any other meaningful order. This makes tools like rsync extremely complicated, with loads of footguns and still not solving the problem well. It feels especially bitter because in exceeding majority of cases you don't want tools like rsync to deal with named FIFO or device files or sockets etc. but you get accidentally but painfully bitten by them every now and then.

drdaeman 4y ago

> Example: Tell me, is this a file or directory? A directory is a file (and IIRC e.g. Plan 9 decided they should be readable just like normal files and there shouldn't be any special readdir syscalls). You can see its attributes to figure out the rest. If not for strong Linux limitations (because of alleged hardlink knot-tying problem) and belief that it just cannot be both, transparent archive access through a filesystem would be a thing. As well as metadata access (`play ./file.mp3` vs `edit ./file.mp3/id3v2`). People of the past seemed to have paid great attention to interoperability and effort to make common interfaces; folks of the modern age ('00s and later) love unique and completely incompatible solutions to the same problem.

christophilus 4y ago
Neat. I’ve often wished I could cat a directory or ls a file. Plan9 sounds like something I would have enjoyed using.
- enriquto 4y ago
  > I’ve often wished I could cat a directory This was possible in the beginning. But then came the moral police and deprived us of this freedom, because they deemed it to be "confusing". See, for example, The Unix Programming Environment, by Kernighan and Pike, page 51 [0]: Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. (...) The time has come to look at the bytes in a directory: $ od -cb . [0] https://archive.org/details/UnixProgrammingEnviornment/page/n61/mode/2up https://archive.org/details/UnixProgrammingEnviornment/page/...

dredmorbius 4y ago

'ls -l' will tell you the basic information of a given listing, including whether it's a normal file, directory, symlink, block device, named pipe, etc. stat(1) will provide additional information on a file. file(1) will not only distinguish between filesystem=level distinctions, but will make a remarkably good guess as to what the file contents of a normal file are, based on magic(5).