Re: RFC: Illegal Characters in File Names

[John Newbigin <jn@it.swin.edu.au>]

Bryan Henderson wrote:
...
> But really, the idea of making a terminal send a command is a red herring. 
>  The problems of non-text filenames are more basic:
> 
> I have personally lost a lot of time in cases where 'ls' misled me as to 
> the contents of my directory.  (I eventually found the --almost-all and 
> --human-readable options of GNU Ls and have been much happier since).
So your problem is that ls does not do what you want by default.  The 
issue of 'control codes do bad things to terminals' is as you say a red 
herring.  I see a suspect file, even if the name does not contain 
control codes, the file it's self might. By catting the contents I am 
still vulnerable for the same reason.  My tools (in this case cat) don't 
do what I want (such as escape the control codes).

In the same way, if I don't know how to use any other tool, I might be 
misled by incorrect output.


> 
> I wouldn't stop at nonprinting characters.  Punctuation, especially spaces 
> and tabs, cause a lot of trouble too, for very little gain.
These all give me the shits too, but I don't use them.  I try to educate 
other users but I don't force them not use use them.  Particularly 
windows users using samba like to use spaces.

> 
> As I've said, I don't want to take away your weird filenames.  But I'd 
> like to get rid of mine.  I'd rather have an untar fail than create a 
> filename that's going to cause me grief.
Exactly.  You should have control over your environment.  A per user 
filename filter could do this.  You can turn it on and off, configure 
special encodings whatever.  If all your filenames turn to shit, the 
system still works and you don't impact other users.  If you don't like 
the files other people leave in /tmp then use a private /tmp.  (Why 
don't we have a vfs which can make my private tmp appear on /tmp?)

Preventing these characters at the filesystem is not good because it 
impacts on people who want (perhaps misguidedly) to use them.

> 
> 
> In one of my earliest encounters with a computer, someone distributed a 
> program that created a status file with a command line editing character 
> in its name.  He did it to try to stop people from deleting it -- it was 
> impossible to delete it with a typed command.  He didn't think through 
> just what effect attempting to type such a command would have.  What it 
> did was create a command that says, "delete the file I most recently 
> worked on."  I deleted 3 important files before I realized what was going 
> on.
We know that all valid filename characters can be entered into a bash 
shell if correctly formatted & escaped.  There are no impossible to 
delete file names (except for perhaps, impossible to create file names, 
which fsck should fix).

If people write software that does silly things then that software needs 
to be fixed.  Your own admission is that the author did not think about 
what they were doing.

The unix fs is a bit like C++.  You can do heaps of stupid things (c++ 
multiple inheritance, operator overloading) but you probably shouldn't. 
  Just because you don't however, does not mean that you should remove 
them from the language.