[bug #60383] [feature-request] let find read files from stdin or file.

[Paxsali]

Follow-up Comment #2, bug #60383 (project findutils):

There are more things to consider.

For instance, if a file in the input list is a directory, then the default
settings ([-H] [-L] [-P]) need to apply, unless explicitly stated otherwise.

This means that if directories are elements of the input list, it should be
treated equivalent as if they were given in the [starting-point...] section of
paths and they will be recursively searched (unless one explicitly does not
want that),
which must be explicitly mentioned in the manual, since it may confuse users
otherwise, who might think the input list is absolute and nothing outside of
it can be searched.

Btw TAR uses the same behavior with it's -T switch. If a file in the input
list is a directory, it will be archived recursively, no matter if it's
sub-files/dirs weren't elements of the provided input list (unless of course,
one explicitly specifies --no-recursion).
It is my understanding that the same behavior is used/applied for this "new
feature".

With regards to your concerns mentioned:

I agree and there is always the possibility to simply provide a new "mode of
operation" for find, such that the named conflicting will not occur by design
(your examples: -ok, -okdir).

About the "files or paths starting with -" problem I must admit I don't see
why this should be a deal breaker for this particular feature-request.
The same basic problem exists for the current version without such a feature
as you described it "as currently is" / "in general".

The easiest way to solve this issue, IMHO, is to use double slashes "//" at
the beginning of a path spec to indicate a "literal" starting point, e.g.:

$ find //-evil //-pathnames //-dont //-scare //-me -ls

When above "hypothetical find version" sees such path specs, it removes the
"//" internally and treats the rest as a literal path specification.
This is just from the top of my head. It's off-topic, looks ugly, but it would
work 100% as slashes and null bytes are the only special characters to
consider.
Null bytes obviously you can't use, so you're stuck with doing something with
slashes and since double slashes are "illogical", one could use that as a
special prefix.
Maybe super-fancy new and cool programming languages will remove the null
bytes restriction in the distant future... not that anybody misses null-bytes
(where's my garlic and cross?).

Back to topic:

I take it as given that the implementation will consider such details as how
to interpret the input list and provide multiple choices for it.
Null terminated lists should ofc be the minimun supported option, as they're
the most powerful and safe ones, but I see no reason for not also supporting
newline terminated input lists.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60383>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/