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/