Hacker News Reader

It's not. Just look at what limitation of such sort lead to in Windows, where each application tries to serialize an otherwise perfectly valid filename into a set of characters allowed in Windows. Of corse, majority of them never get that right.

Unix is tools, not policy. It's what you make of it, and that's its beauty.

I’m agree on the last point - but I’ll point out that at this point we already have policy limitations on what makes a file name.

As I understand it most unixes require that they are composed of valid characters (not random bytes (or more evilly bits)) and can be no longer than a file system imposed length (commonly 255 bytes).

What do you mean by valid characters? The file name usually can include any characters except the forward slash. There are, of course, filename limitiations, which are implementation specific.

Well, any character but 0x2f and 0x00. :P

I was thinking that - but more than that I was thinking of FSs that allow UTF8 or UTF16 characters - which do not allow invalid code points. But from this morning's research that seems to only be NTFS and UTF16, which is not exactly a "unix" FS.

I don't think that's strictly true. Most unix filesystems "allow" UTF-8 characters, specifically because they treat the filename only as an array of bytes and don't interpret that array at all. Perhaps NTFS does do some work to present it as UTF-16 codepoints, I don't know, but it's far from the only file system that allows this to happen.

He may have meant accept only UTF-8/16. That is the very nice thing about UTF-8 though is that it plays so nice with routines that can accept ASCII or Latin-1. You can't use old routines to character count/change case/etc., but at least they won't corrupt your string by accident.

> I'm sure most reasonable people would agree that (simple) unicode characters are fine,

What's simple? Chinese? How about vertical scripts like Mongolian? http://en.wikipedia.org/wiki/Mongolian_script What about composition characters, where unicode is basically acting like a set of instructions just like a terminal control character?

> what possible use is there for having control characters in a filename, like newline or carriage return?

Terminal control characters are only a problem because the terminal is interpreting them due to another ancient broken paradigm, but the fact is that these filenames exist. They're present right now. You're breaking old code by changing the rules on them. Keep 'rm' from operating on them, and then I can't delete them when some stupid program goes and creates them. Keep 'vi' from operating on them and I can't look inside to see wtf caused it. That's what I meant by re-quoting Linus there. You don't get to pick the reality that you already live in, and the reality that we live in has silly messy filenames with "beep" in them.

Besides, unless you go hyper-restrictive like [A-Z0-9]{1,8}, there are going to be edge-cases. Just spaces are enough to trip up bad shell scripts. Spaces are effectively control characters as far as the shell is concerned. If you allow spaces, you already have to deal with the "bad" filenames.

I don't pretend to have a good answer, so I guess my point here is that these kinds of issues are more deep-seated than they appear at first. The fact that "ls" allows what's basically an injection attack on your terminal isn't ls's fault, or necessarily the terminal's fault, or the shell's fault, it's because of a whole generation of bad assumptions and "good enough" design that adds up across these tools. Just "limiting filenames" seems like a quick fix, but isn't going to fix it because that's not the root of the problem.

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).

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

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.

> 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.

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.

Why are ASCII regarded as "normal characters", but Kannada, or Hangul, or Arabic, or whatever are "special characters"?

There is a reasonable, non-"culturist" answer to your question, which is that ASCII admits of a monospace typesetting in which each character is fully isolated in its own box and does not interact with any others across the box, nor are there any combining marks or any of the other vagueries of Unicode, and there's a very limited number of such characters. Possibly Hangul can claim that, I know Arabic and some other scripts can not. Other languages that can claim this include I believe all European languages (the accents are rare enough you can just represent them as characters of their own rather than combining marks) and Cyrillic. None of the ideographic languages can currently claim this, though I heard rumors that Japanese and Chinese are both experiencing some heavy pressure internally to go to an alphabetic subset of their language that actually would meet this criterion. (And not due to authoritative mandate, but rather the natural flow of language.)

It is a problem when you have languages with fundamentally different rules trying to share the screen, and that is also not a culturist observation; indeed one would think that denying this would be the culturist position.

For Japanese, in a Unicode context, I've never seen a combining mark actually used.

While the precombined versions are much more common, Japanese does have combining characters to add voiced and semi-voiced marks to syllabic characters (e.g, か vs が, は vs. ぱ).

It does, but I've never seen them used in a Unicode context.

The ideographic languages can't claim "a limited number of characters". (7-bit) ASCII fits on a typewriter ball. (By "limited", I meant small, rather than merely finite.)

Of the various points I mentioned, in modern times this is probably the least important, now that RAM, ROM, and CPU are so dirt cheap. This wasn't always true.

> So programs that show the filename in the title bar: how do they display it?

That hardly sounds like a file-system issue. That's an application and UI-design issue.

Just because you think some of these issues are hard and you don't know how to deal with them on an application level (beacuse you haven't had to yet), doesn't make that a valid reason into limiting the capabilities of the file-system.

Shouldn't display be a feature of the locale?

> Pretty inhibiting for a speaker of Kannada that they can't name their résumé file with their own name.

That's what transliteration is for. I have no problems writing my name transliterated into the Latin script.

> 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?

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 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

I think tools should ideally not create strange filenames without forcing(and for some tools as gui tools should be missing the force override). Ideally they should still be able to view and delete them. If you a file with that type of name and edit and attempt to save it, the tool should offer to rename it(deleting the version with the "bad name") by default but allow an override to save with the old bad name.

The fact is, we already support filesystems on UNIX with restricted filenames (eg: FAT and NTFS). If you ban terrible filenames from the filesystem, those filenames would not exist because they could never be created in the first place.

Yeah, but we don't have a time machine, so we don't get to pick the reality where all UNIX-native filesystems restricted filenames like FAT. This isn't something that you can retroactively change, so we are stuck on this reality and need to find ways to cope.

Ignoring the fact that non-terminal users regularly want spaces, hyphens and newlines in their filenames since they have visual purpose...

The argument in favor of newlines is the same argument in favor of spaces in filenames or filenames starting with hyphen: the filesystem should not be restricted by bash and other shell scripts continual confusion between data and instructions. We should fix/replace lazy programs, don't try to fix lazy programming by neutering the system.

I think the correct action should be to design shell scripting languages that are robust about data versus instructions. The lack of robustness in shell scripting languages has been a burden since their inception. Restricting the filesystem won't stop problems with shell scripts making the same mistakes on other kinds of data.

So one solution is to replace all the popular shells from the ground up, throwing away about 30 years of history because they're "not elegant". (Ignoring the fact that almost every attempt to do this in the past has been a resounding failure).

The other solution is to agree not put overly weird shit in filenames.

Which seems more likely to happen in our lifetime? Which would you rather code against?

I'm baffled that people are so hell bent on what "should" be allowed that they're ignoring the fact that allowing any possible character introduces exceptional complexity while offering extremely marginal benefits. I mean, imagine trying to make a gui for a filesystem browser that allows for characters that flow both up and down along with left and right. And newlines all over the place. It'd be a mess. I mean.. why? Is filename expressivity really such a major deal?

If you're looking at "30 years of history" then shells have endured "weird shit in filenames" for their entire existence and civilisation hasn't collapsed. Clearly, we don't need to change anything for them so I don't think filesystem are going to recant on their longstanding policies by making any changes to further accommodate scripting languages in our lifetimes.

Meanwhile, new shells (or new versions of shells) come and go all the time. Could one of these implement a foolproof (or at least, foolresistant) way of escaping arguments? Maybe.

> The other solution is to agree not put overly weird shit in filenames.

If you don't put weird shit in your filenames, I won't put weird shit in mine. Let's not bother the kernel with our contract. :)

That doesn't solve the security vulnerabilities caused by weird filenames.

I think it shows that contemporary shell programming never was exposed to as much malicious misuse as common web-apps. I mean "program ★foo★" is basically equivalent to "SELECT ★ FROM table WHERE foo = '$bar'" when provided with arbitrary, user-provided input. And you see a lot of this in typical shell-scripts. And for output messing up our terminal, no one ever uses "<? print($input) ?>" to put things in HTML pages without escaping it.

So, yes, if you are writing scripts that should be resilient to all malicious or accidentaly provided input, it's a lot of work, and you better have code for these common operations (input, output of user-provided filenames) in all applications that try to do useful things with filenames. And probably it means that you cannot use programs not providing a "--" parse-stopper or put the data on the end of a "ssh" command-line.

And there will always be an application confused by some random other seemingly innocuous character that the kernel "still" allows in filenames.

So the solution probably is not to limit the allowed characters, and also not to try to fix the useful and working parts of shells, but to augment them with the equivalents of html_escape() and mysql_prepare("...?...")/mysql_escape() where needed (to stay in the realm of SQL and web-apps).

Who owns the filename? If the user owns the filename, than it is incumbent on the system to be able to handle arbitrary names. If the user doesn't own the name, then the system must not expose the name to the user. c.f. filename extensions.

If a human script is read top-to-bottom, then the computer should handle that without complaint. This may not be possible in all cases immediately -- there's far too much Unix braindamage weighting the world down to throw it all away at once -- but we should all be trying to liberate humans from the dead hand of New Jersey.

Ignoring the fact that non-terminal users regularly want spaces, hyphens and newlines in their filenames since they have visual purpose...

I'll happily agree with the spaces, because people like filenames to look like short phrases. But I've never seen a human make filenames with a leading hyphen (plenty with hyphen within the word) nor with a newline.

I could imagine that somewhere there is a person or two that likes to make hyphen-led filenames to try and sort things, but this is catering to the outliers. I can't imagine the use case for anyone to intentionally make a filename with a newline in it, and haven't seen such a thing, human or program-made. I think it's not common or valuable enough a thing to hamstring everyone else.

Edit: solution in the traditional linux way: off by default, but you can always compile them back in if you love them that much :)

I once saw humans making filenames like --splitwork --verbose -tdxh input.txt

And by "once", I mean "yesterday". Now, is it reasonable to design a system that takes input flags through the names of input files? No. It is clever, yes, but it's not reasonable. The fact of the matter is however that these usecases, for better or worse, do exist. We should not change filesystems to break these systems (broken as they are already) just because bourne-related shells aren't fond of them.

I have done a lot with users of all sorts. I see a lot of spaces and hyphens inside files, but I have never seen either a leading hyphen or an embedded newline.

Are there cases where these would be desired in GUI environments? Why and what is the use case?

I've regularly seen:

-- Myfile With Emphasis --.txt

Basically, users will try to use any punctuation they see on their keyboard to adorn their filenames.

Interesting. So maybe this should be configurable.

This is solving the problem in the wrong place. The proper way for OS is to treat filenames as binary sequences like Linux does and have no problems.

The problems that arise elsewhere should be solved elsewhere.

So instead of solving it in one place, we should solve it in hundreds of places?

If the problem is the shell like I assert, there are probably fewer shells than filesystems

Your character set's control character is another character set's perfectly normal printable character.

As for making the kernel enforce a single character set for the filesystem: No. No. No. Put another way: No.

http://yarchive.net/comp/linux/utf8.html

From Al Viro:

    Bullshit.  It has _nothing_ to characters, wide or not.  For system filenames
    are opaque.  The only things that have special meanings are:
            octet 0x2f ('/') splits the pathname into components
            "." as a component has a special meaning
            ".." as a component has a special meaning.
    That's it.  The rest is never interpreted by the kernel.

What happens if I try to create a filename using a character set in which octect 0x2f appears as part of a multibyte character? Oops?

I think neither ISO 2022 nor UTF-16/32 have never seen use in filesystem, exactly for this reason. The closest analogue of this problem in non-POSIX system is Shift_JIS, which can contain a backslash in a multibyte character (which I regard as a stupidity, given the possibility of using FD/FE bytes instead).

> can contain a backslash in a multibyte character

This is potentially confusing but, ultimately, fine. The problem is slash (byte 0x2f, in ASCII '/') in multibyte characters.

In Windows backslashes are analogous to slashes in the path.

You can't do that. That's one of the upshots of the way Linux handles filenames.

Linus has talked about this in the past... because of the fact that Linux only cares about 1 "special" character (the ASCII slash), the only sensible way to do unicode for filesystem names is to use UTF-8, which is backwards compatible with ASCII and thus obeys the kernel's expectations.

It's one of those "you can have any color car so long as it's black" ultimatums... you can use whatever encoding you want, so long as it uses 0x2f for slashes, and slashes only.