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

[Bernhard Voelker]

Update of bug #60383 (project findutils):

                Severity:              3 - Normal => 1 - Wish               
             Assigned to:                    None => berny                  

    _______________________________________________________

Follow-up Comment #1:

Thanks for the request, and the examples to illustrate the idea behind.

Actually, I suggested such option already in
https://savannah.gnu.org/bugs/?58205 .
The discussion came from the problem when a given path name starts with a
"-";
this screws up the argument parsing, and the only way out is to use absolute
path names
or those relative to the current directory: './-somepath'.
It wasn't seen worth adding at that point.

Still, I see the issue that some other tool has pre-filtered path names and
needs
to pass them to find(1) for further examination.  This is hard to achieve in
a
secure and performant way.

For a most-secure way, i.e., to avoid surprises with unusual file names,
the input file should contain the entries separated by NUL characters.
The new option would be named '--files0-from=FILE' like in du(1) and wc(1)
from the GNU coreutils, and accept the special FILE name "-" to read from
standard input.


# Existing synopsis: pass starting points before expressions:
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [--] [starting-point...]
[expression]

# Alternative synopsis: read starting points from file:
find [-H] [-L] [-P] [-D debugopts] [-Olevel] -files0-from=FILE [--]
[expression]

# e.g.
... | find -L -files0-from=- -type f ...


FWIW: using '-files0-from=-' would conflict with actions which require a
confirmation from the user: -ok and -okdir.  The implementation would/will
have to disallow this combination.

After all - and unless some other conflicts or drawbacks are raised here -,
I'm 60:40 for adding this option it.

    _______________________________________________________

Reply to this item at:

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

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