> This points up, perhaps, the real problem.  It seems to me 
> that Unix is too permissive with respect to the characters that 
> can be embedded in file specs.  I've never been able to come 
> up with a good reason (other than that it eliminates one check 
> in the directory entry creation code) why an OS should accept 
> file names including control characters such 
> as '\n', '\b' and the like.  I've reluctantly become convinced that
> user need to be able to put blanks into file names; but this is not
> much of a problem compared to '\n'.  
>
> [ ... ]
>
> The simple change (which will never happen) is to simply forbid
> all characters for which isprint() is not true from appearing in
> file specs.  This is permitted by Posix, if I recall, and would
> not break any other than the most obscure (and non-portable)
> applications.  

A better question is, why should those characters be _forbidden_?

Unless i'm mistaken, isn't 'isprint()' locale-specific?  What locale
would you force people to use?  "C"?  Should not people in countries
with 'special' characters (say, 'c's with cedillas...) be able to use
them in file names?  "oh, but they're not printable in the C locale."


To my mind, the file system should be minimally intrusive in
specifying what parts of the character set the user can and can't use.
The UNIX API reserves / and NUL, and there are times when i've wanted
to use / in my file names...  (This is a reason why i don't
particularly like 'magic' filenames like AFS's @sys, even though i
think they're really nice to have.)



chris