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

Follow-up Comment #7, bug #60383 (project findutils): @James (#comment3): thanks for listing those restrictions; I also thought about them in this way. Especially no. 1 (the seek position in the file) would maybe be tricky to to ensure. But I think it's an extreme corner case to continue process

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

Follow-up Comment #6, bug #60383 (project findutils): I tend to agree with Andreas. ___ Reply to this item at: ___ Message sent via Savannah https://

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

Follow-up Comment #5, bug #60383 (project findutils): [comment #1 comment #1:] [...] > 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. I actually think if you are extending find in this non-portable

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

Follow-up Comment #4, bug #60383 (project findutils): Ok now that discussion is off-topic, actually, but regarding this: [comment #3 comment #3:] > We cannot use //x as a way to escape x, because in POSIX path names matching //[^/] are `special` and have an implementation-defined significance, wh

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

Follow-up Comment #3, bug #60383 (project findutils): We cannot use //x as a way to escape x, because in POSIX path names matching //[^/] are `special` and have an implementation-defined significance, which `find` cannot know (find is intended to run also on non-GNU systems). The difficulties aro