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/
