Apology to Bill Gates (was Re: ASV module, CVS modules)

[Andrae Muys]

sjmachin at lexicon.net (John Machin) wrote in message news:<c76ff6fc.0203011028.4434415f at posting.google.com>...
> Michael Hudson <mwh at python.net> wrote in message news:<ud6yowepw.fsf at python.net>...
> > Skip Montanaro <skip at pobox.com> writes:
> > 
> > >     John> Python, starting from a Unix background, where there is evidently
> > >     John> no such thing as an invalid character in a file name, ...
> > > 
> > > I believe "/" is not allowed in Unix filenames.  Not sure if this is
> > > escapable or not.
> > 
> > Don't think so.  NULLs are out, too.
> 
> It is not a case of "not allowed". You simply can't supply a file name
> containing a "/" or a NUL (not a *NULL*) because "/" is interpreted as
> a path separator and NUL as a string terminator.
> 
> My point was that Unix doesn't proactively check to see if you are
> trying to create a file whose name you may never see again.

Or more precisely, the unix creat/open syscalls don't take a filename
as a parameter, rather they take a pathname which is interpreted with
the above definitions in place.  As character escaping are considered
a UI issue, not an OS issue, all other characters are interpreted
literally.

If there are good UI reasons for forbidding the use of non-printing
characters in filenames, then the UI is responsible for enforcing
that.  The unix OS takes the reasonable position that if a program
considers it necessary to create such files, it isn't the OS's place
to refuse.

As such it is impossible for creat/open to be passed an invalid
argument under the various POSIX standards, therefore EINVAL can't
happen.  After all, even under NT, if the underlying filesystem might
support a given char, the argument can't be considered invalid. 
Therefore given that the definition of ENOENT (as listed in the linux
manpages, my copy of the POSIX function def's is at home) is

       ENOENT A directory component in pathname does not exist or
              is a dangling symbolic link.

The error for a filename with an embedded char unsupported by the
underlying filesystem is probably best described by ENOENT.

Andrae Muys

P.S.  as a matter of interest I had a play to demonstrate
non-printable filename handling on a linux box I have available to me:

Consider the following...
[root at ttdev7 test]# touch ^M^L^D
[root at ttdev7 test]# touch hello^Aworld
[root at ttdev7 test]# touch helloworld
[root at ttdev7 test]# ls
???  helloworld  hello?world
[root at ttdev7 test]# rm -i *
rm: remove `\r\f\004'? y
rm: remove `hello\001world'? y
rm: remove `helloworld'? n
[root at ttdev7 test]# ls
helloworld
[root at ttdev7 test]#

Note the control char's are inserted as literals using ^V^x as this is
bash and readline uses ^V to flag control char literals.  (the only
exception to this appear to be ^C).  Also note \r[eturn] == ^M, and
\f[ormfeed] == ^L.