How do I deal with (null) filenames?

[Dr. William B. Busa]

	Thanks to all who responded. Responses fell into two categories:

	1) Those who accepted my assertion that filenames displayed by
	ls as (null).001, (null).002, etc. really did begin with a NUL
	character.

	2) Those who rejected the possibility of UNIX producing a filename
	beginning with a NUL. This was best explained by guy at auspex.com:

"The UNIX calls to create files, etc. take C-language strings as
arguments, and those strings end with '\0', so a call passed the
characters "\0.001" would assume that the string being passed was a null
string "", NOT a string with a '\0' followed by ".001" "

Consequently, as many suggested, it was most likely that my "(null)"
filenames actually contained the characters '(' 'n' 'u' 'l' 'l' ')'; a
sorted ls listing would still place these before . and .. since '(' is
ASCII 40 while '.' is ASCII 46.

This, as it turned out, is exactly correct -- my files did not contain any
NUL characters in the names; rather, they were named "(null).001",
"(null).002", etc. I had been confused by my attempts to change these
names with commands like 

		mv (null).001 foo.001

which, of course, generated error messages. The simple solution was to
quote the filename:

		mv "(null)".001 foo.001

	An additional interesting comment was supplied by Chris Torek
(chris at mimsy.UUCP):

	"The other thing to do is fix the software. Probably a 'helpful' C
library is receiving a call of the form 

	char *p = NULL;
	int seq = 0;
	...
	(void) sprintf(buffer, "%s.%3d", p, seq);

and instead of crashing the program (thus pointing directly to the bug),
it is formatting '%s' with an argument of (char *)0 as the six letter
sequence '(null)'. Suns and 4.3BSD-tahoe machines do this, for instance."

	I haven't had a chance to check this yet, but it *is* interesting
to note that my buggy software is running on a Sun 3/110 running SunOS 3.3
(4.2BSD). 

	Again, thanks to all! Sorry the question wasn't *nearly* as
interesting as it originally seemed!