Update of bug #39824 (project findutils):
Status: None => Works For Me
Open/Closed: Open => Closed
Summary: Add suggestion 'ls | tr \\n \\0 | xargs -0 command'
to xargs man page => Add suggestion 'ls | tr \n \0 | xargs -0 command' to
xargs man page
_______________________________________________________
Follow-up Comment #4:
As you point out
find ... -print0 | tr \\n\\0 \\1\\n | grep ... | tr \\1\\n \\n\\0 | xargs -0,
is cumbersome. But it's also pointless since find has -regex.
There are plenty of misconceptions about Unix filenames. One of them, as you
point out, is that they don't/can't contain blanks. Of course, they can.
But a much more pervasive misapprehension is that file names are text. They
are not; instead they are byte sequences, in which system calls consider '/'
to be special, and which are terminated by \0 when presented to the API.
The critical difference is that nothing on a Unix system requires or enforces
that a directory name has the same character encoding as its parent. So
there is no single locale configuration which will allow one to correctly
process a general path name as text. This includes the "C" locale (as a
trivial example, it fails to correctly collate characters beyond <DEL>). For
this reason processing path names with grep or sed, while common and popular,
is probably never going to be without problems, though I suppose one could
invent a kind of they're-just-bytes locale definition.
Anyway, because this kind of use of tr perpetuates misunderstandings about
what bytes values can exist in file names and what they mean, I wouldn't
really want to include a "tr" command acting on file names in the
documentation, except perhaps as a cautionary example.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?39824>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
