> On Mon, Mar 26, 2001 at 11:09:54AM -0500, David Korn wrote:
> > Our current find implementation (the AST software), also supports -print0
> > but I would recommend against this since the output format
> > is no longer a text file that can be processed by many of the
> > standard utilities.
>
> True; that is an unfortunate limitation of the SVR4 tools.
> It still doesn't solve the cpio issue.
I don't know what the issue is with cpio since pax allows
you to specify the directory that you want to save.
> If find, xargs, and cpio can be made safe and useful, why not?
There was some discussion about xargs before the 1992 standard
but there was concern about backwards compatibility.
>
> The GNU tools strive to be 8-bit clean and usually support embedded NUL.
The POSIX standard require 8-bit clean.
I don't think that bash and many other GNU commands handle embeded NUL's
and there is no way to pass embedded NUL's through the environment.
It would take a lot of work to require that all text command
handle embedded NUL characters.
> A few of the utilities support NUL as a separator, and these are often
> sufficient to do real work. Off the top of my head:
>
> find -print0, -fprint0
> xargs -0
> cpio -0
> sort -z (since on UNIX, -z is an unrelated, deprecated
>option,
> it should perhaps be -Z)
> [e]grep -Z, -z (for filename and line terminators)
> gawk 8-bit clean.
> tr preserves NULs (so does /usr/xpg4/bin/tr on Solaris)
This is required by POSIX.
> diff -a forces text comparison
>
> One can also use GNU tr to swap NUL and newline, then swap them back later:
>
> find ... -print0 | tr '\0\n' '\n\0' | ... | tr '\0\n' '\n\0' | ... | xargs -0
>...
This still won't work for commands that fail when they encounter
NUL characters or else discard them. Have you tried using a shell
script for ...?
>
> Even without Perl, it is clear that solutions to real file-handling problems
> (that are potential security holes) are possible with this subset of the
> text utilities.
This isn't clear. Using the xargs command can create security
problems, (which is why I never use it), but since it is never
necessary, I don't see why you make this claim.
>
> Regards,
>
> Bill Rugolsky
>
David Korn
research!dgk
yyy@xxxxxxxxxxxxxxxx
|