3 ms·

By simple I mean this: * Printable (space excluded) * Doesn't change the flow/layout of characters (no weird reverse characters or superscript/subscripts or c

By simple I mean this: * Printable (space excluded) * Doesn't change the flow/layout of characters (no weird reverse characters or superscript/subscripts or characters that flow up/down). Will that make everyone happy? Of course not. But it's pretty much "expressive enough" and it makes dealing with filenames 10x simpler. Which policy seems more realistic: A) sensible restrictions on file names that will please the majority of people and keep most programs working, while slightly annoying a lunatic fringe that wants EVERYTHING. B) Require that every program that handles files in some capacity can handle every single possible weird unicode and control code subtlety in existence? (Keeping in mind that even browsers, some of the most complicated pieces of software in existence, still tend to screw up the corner cases).

toast0 13y ago
If you're going to whitelist characters from unicode, we're going to have several problems with managing the whitelist: a) overhead for the whitelist is going to be an issue on some systems b) I'm going to need a kernel update every time there's a new useful code point for example, the Indian Rupee Sign http://www.fileformat.info/info/unicode/char/20b9/index.htm http://www.fileformat.info/info/unicode/char/20b9/index.htm
- dwheeler 13y ago
  You can just check "is it UTF-8 encoded?". Then it doesn't matter when a new code point is added, it would still be correctly encoded. You could make this a configurable kernel option; when enabled, filenames can only be created when they encode with UTF-8. The next big problem is control characters. But really, the only people who need control characters embedded in filenames are people breaking into computers using them. It doesn't matter if you use a GUI or a CUI, people generally don't embed newlines, or escape, or tabs in filenames. The leading "-" is probably more controversial, but the POSIX standard specifically notes such filenames as nonstandard.
ketralnis 13y ago
> Will that make everyone happy? Of course not. But it's pretty much "expressive enough" and it makes dealing with filenames 10x simpler. Simple enough for a Western language speaker, sure. Pretty inhibiting for a speaker of Kannada that they can't name their résumé file with their own name. > Require that every program that handles files in some capacity can handle every single possible weird unicode and control code subtlety in existence? I assert again that once you allow spaces, you're already in the situation that you need to treat filenames as sequences of bytes that need quoting. Also, I want to point out again that almost all of these problems are only when writing shell scripts. C programs or e.g. GUI applications with file pickers tend (with exceptions of course) to not have these problems since you get the filenames into them.
- overgard 13y ago
  Ok so fine, we allow people to write filenames top-to-bottom. So programs that show the filename in the title bar: how do they display it? Really big title bar? Align the title bar on the left or right? What if I mix english and Kannada? What then? Or what if I start with an english word in the terminal, and then switch to kannada, what's the terminal supposed to do? I haven't used a lot of asian language systems, but I'm going to guess two things that I'm pretty sure are true: A) they're already implicitly dealing with these restrictions, whether the file system enforces it or not B) they probably already have workarounds to deal with these cases anyway. (alternate scripts or whatever). Regardless of culture, I'm going to make what I think is a pretty obvious statement: good filenames are easy to type and unambiguous. If your filename is neither of those, it's not a good filename. The point of a filename isn't to be as expressive as possible, it's to be universal, descriptive, and easy to work with. None of that requires special characters. With regard to the space thing, I think it's overblown. Spaces are common enough that good software engineers think to handle it. Newlines in files? I've /never/ seen that, even though it's possible. Also, space doesn't require an escape character. Once you start getting to newlines, it does. Once you start introducing escape characters into it, it's an entirely new layer of complexity.
  - hdevalence 13y ago
    Why are ASCII regarded as "normal characters", but Kannada, or Hangul, or Arabic, or whatever are "special characters"?
josteink 13y ago
> But it's pretty much "expressive enough" You mean like ASCII was "expressive enough" until people whose language was not English started using computers? Your western bias shows. That "expressive enough" attitude got us code-pages and a million different encodings to cope with the limitations we had put upon ourselves, and the related (and sometimes impossible) compatibility and inter-op issues. Let's not walk into that one yet again, shall we?
- selmnoo 13y ago
  A really interesting case is Urdu. In Nastaliq script, the Urdu language word-wise goes right-to-left... diagonally. Here's a picture: http://i.imgur.com/nIHmZJc.png http://i.imgur.com/nIHmZJc.png See how every next letter is just a little bit lower than the one preceding it? That's Nastaliq script, it goes left-down-ward. As you could imagine, it's a special hell supporting this language. What's happened now is... a compromise has basically been made. Nastaliq is how Urdu had predominantly been written for years and years... but with growing usage of computers, even native Urdu speakers are abandoning it, because there's such poor support for it. This article talks a little more about this: https://medium.com/stories-that-matter/9ce935435d90 https://medium.com/stories-that-matter/9ce935435d90

toast0 13y ago

If you're going to whitelist characters from unicode, we're going to have several problems with managing the whitelist: a) overhead for the whitelist is going to be an issue on some systems b) I'm going to need a kernel update every time there's a new useful code point for example, the Indian Rupee Sign http://www.fileformat.info/info/unicode/char/20b9/index.htm http://www.fileformat.info/info/unicode/char/20b9/index.htm

dwheeler 13y ago
You can just check "is it UTF-8 encoded?". Then it doesn't matter when a new code point is added, it would still be correctly encoded. You could make this a configurable kernel option; when enabled, filenames can only be created when they encode with UTF-8. The next big problem is control characters. But really, the only people who need control characters embedded in filenames are people breaking into computers using them. It doesn't matter if you use a GUI or a CUI, people generally don't embed newlines, or escape, or tabs in filenames. The leading "-" is probably more controversial, but the POSIX standard specifically notes such filenames as nonstandard.

ketralnis 13y ago

> Will that make everyone happy? Of course not. But it's pretty much "expressive enough" and it makes dealing with filenames 10x simpler. Simple enough for a Western language speaker, sure. Pretty inhibiting for a speaker of Kannada that they can't name their résumé file with their own name. > Require that every program that handles files in some capacity can handle every single possible weird unicode and control code subtlety in existence? I assert again that once you allow spaces, you're already in the situation that you need to treat filenames as sequences of bytes that need quoting. Also, I want to point out again that almost all of these problems are only when writing shell scripts. C programs or e.g. GUI applications with file pickers tend (with exceptions of course) to not have these problems since you get the filenames into them.

overgard 13y ago
Ok so fine, we allow people to write filenames top-to-bottom. So programs that show the filename in the title bar: how do they display it? Really big title bar? Align the title bar on the left or right? What if I mix english and Kannada? What then? Or what if I start with an english word in the terminal, and then switch to kannada, what's the terminal supposed to do? I haven't used a lot of asian language systems, but I'm going to guess two things that I'm pretty sure are true: A) they're already implicitly dealing with these restrictions, whether the file system enforces it or not B) they probably already have workarounds to deal with these cases anyway. (alternate scripts or whatever). Regardless of culture, I'm going to make what I think is a pretty obvious statement: good filenames are easy to type and unambiguous. If your filename is neither of those, it's not a good filename. The point of a filename isn't to be as expressive as possible, it's to be universal, descriptive, and easy to work with. None of that requires special characters. With regard to the space thing, I think it's overblown. Spaces are common enough that good software engineers think to handle it. Newlines in files? I've /never/ seen that, even though it's possible. Also, space doesn't require an escape character. Once you start getting to newlines, it does. Once you start introducing escape characters into it, it's an entirely new layer of complexity.
- hdevalence 13y ago
  Why are ASCII regarded as "normal characters", but Kannada, or Hangul, or Arabic, or whatever are "special characters"?

josteink 13y ago

> But it's pretty much "expressive enough" You mean like ASCII was "expressive enough" until people whose language was not English started using computers? Your western bias shows. That "expressive enough" attitude got us code-pages and a million different encodings to cope with the limitations we had put upon ourselves, and the related (and sometimes impossible) compatibility and inter-op issues. Let's not walk into that one yet again, shall we?

selmnoo 13y ago
A really interesting case is Urdu. In Nastaliq script, the Urdu language word-wise goes right-to-left... diagonally. Here's a picture: http://i.imgur.com/nIHmZJc.png http://i.imgur.com/nIHmZJc.png See how every next letter is just a little bit lower than the one preceding it? That's Nastaliq script, it goes left-down-ward. As you could imagine, it's a special hell supporting this language. What's happened now is... a compromise has basically been made. Nastaliq is how Urdu had predominantly been written for years and years... but with growing usage of computers, even native Urdu speakers are abandoning it, because there's such poor support for it. This article talks a little more about this: https://medium.com/stories-that-matter/9ce935435d90 https://medium.com/stories-that-matter/9ce935435d90