3 ms·

> It's not really, though. Yes, if you want to round-trip the name of the file and be fully general over the bad situation provided by the OS. But as soon as yo

> It's not really, though. Yes, if you want to round-trip the name of the file and be fully general over the bad situation provided by the OS. But as soon as you want to display that filename, or really do much of anything with it IMHO, that is mostly not the file system's problem. Bits going into and out of the file system should act as deterministically as possible. If you want to start being 'clever' about these problems, do it in userland.

deathanatos 4y ago
And the point is that this line of thinking introduces a metric crap ton of unnecessary complexity downstream. Yeah, an FS could say that¹. Alternatively, it could say that names are intended to be read by humans, and that names should be a single line, to support things that people reasonable expect to be able to do with a file system, like being able to list the files on the filesystem, without whatever is doing the listing needing to decide if it is going to just say "I can't display raw bytes, obviously, so here's a best-effort of ��.txt" or if it has to invent some sort of grammar to encode/escape bytes into text. I.e., a file system is meant to solve a problem, which is the storage and organization of data, and from that, that names are meant to used by humans is one of the requirements of both the OS & the filesystem. (The OS, as it presents the file hierarchy to userspace, e.g., in the VFS, and the filesystem, as it of course needs to store the data.) By your logic, we should permit nul and '/' in file names, too. ¹and, I mean, most do. Which is why we're in the situation we're in, and why languages are faced with a barrel of bad choices, and why probably 90% of shell scripts fail to properly handle file names. Is this what we want?
- deleted 4y ago
  [deleted]
- comex 4y ago
  > why probably 90% of shell scripts fail to properly handle file names. Is this what we want? If you want to fix shell scripts, you need to ban not just newlines but also spaces. Well-written shell scripts handle spaces properly, but many don't, and Makefiles cannot.

deathanatos 4y ago

And the point is that this line of thinking introduces a metric crap ton of unnecessary complexity downstream. Yeah, an FS could say that¹. Alternatively, it could say that names are intended to be read by humans, and that names should be a single line, to support things that people reasonable expect to be able to do with a file system, like being able to list the files on the filesystem, without whatever is doing the listing needing to decide if it is going to just say "I can't display raw bytes, obviously, so here's a best-effort of ��.txt" or if it has to invent some sort of grammar to encode/escape bytes into text. I.e., a file system is meant to solve a problem, which is the storage and organization of data, and from that, that names are meant to used by humans is one of the requirements of both the OS & the filesystem. (The OS, as it presents the file hierarchy to userspace, e.g., in the VFS, and the filesystem, as it of course needs to store the data.) By your logic, we should permit nul and '/' in file names, too. ¹and, I mean, most do. Which is why we're in the situation we're in, and why languages are faced with a barrel of bad choices, and why probably 90% of shell scripts fail to properly handle file names. Is this what we want?

deleted 4y ago
[deleted]
comex 4y ago
> why probably 90% of shell scripts fail to properly handle file names. Is this what we want? If you want to fix shell scripts, you need to ban not just newlines but also spaces. Well-written shell scripts handle spaces properly, but many don't, and Makefiles cannot.