recursive grep

[Guy Harris]

>> >I wouldn't complain about xargs not being capable of handling
>> >filenames with spaces and newlines.  There are a lot of other
>> >programs that will break under the same circumstances.
>>
>>In which case I'd not only continue to complain about "xargs", but
>>complain about those other programs as well....
>
>The shell (as well as many other utilities) is line oriented, which
>means that it uses whitespace to delimit input lines.

No, that means that it uses *newlines* to delimit lines.  It uses
whitespace to delimit tokens, but you can use quotes to get around that.

>Since you can create them with the shell quoting mechanisms you
>can access them from the shell with the same methods, but these
>are not available to most other utilities.

"Most" other utilities, at least in UNIX as distributed, take their file
names from the command line, and thus the shell quoting mechanisms *are*
available to them.

>So the question becomes one of how you would separate one name from
>another if you were not using whitespace?

'\0', as has already been suggested.  It doesn't have to be the default
separator, but as an option it might be useful - e.g., so that "find |
cpio", which some sites use for backup, won't get confused by files
containing newlines.  (It won't be confused by files containing other
sorts of white space, e.g. spaces.)

>If you want to have spaces or newlines in filenames (which is
>perfectly OK, the kernel doesn't care) you would have to consider
>writing a new shell, a la the macintosh interface.  Otherwise we
>have to live with what we've got (which I am perfectly willing and
>happy to do).

Some people already have interfaces like that; back when I was working
at CCI, the Office Power system had an interface that did allow spaces
in file names, and if it made sense to put a space in a file name, I'd
put it there.  Other systems may do so as well, so at least *some*
programs had better be prepared for spaces in file names, at a minimum -
which includes programs like "xargs", since somebody might do a "find
-print | xargs" that its the directory of a user of such a system.

In other words, the fact that it's inconvenient or impossible to use
file names containing certain characters in *some* programs cannot be
used as an excuse for not fixing at least some other programs -
including, as noted, "xargs" - from being able to handle them.  Or, to
quote the Robustness Principle cited in at least one RFC: "Be
conservative in what you send; be liberal in what you accept from
others;" the latter part means "be liberal enough to accept file names
containing funny characters, since some funny character may decide to
create a file with such a name."