> Unfortunately, neither of these fixes helps if you want to
> 	find whatever -print | filter | xargs command
> since most off the shelf filter commands don't operate on NUL delimited
> strings.

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

This is especially a problem on Unix, with its dependency on 
text filters -- because \n can be embedded in a file spec,
almost nothing useful can *reliably* be done to a list of files
without a lot of non-obvious work.

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.  

--Terry
tmm@mcci.com	tel:  +1-607-277-1029	fax:  +1-607-277-6844