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

[Paxsali]

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

                 Summary: [feature-request] let find read files from stdin or
file.
                 Project: findutils
            Submitted by: paxsali
            Submitted on: Mon 12 Apr 2021 03:11:02 PM UTC
                Category: find
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: None
         Discussion Lock: Any
           Fixed Release: None

    _______________________________________________________

Details:

Hi all,

I was thinking about a very interesting, but admittedly niche use case.

What if I already have a narrowed list of files available, say from a previous
command or stored in a file.

Now what I want is, that "find" instead of literally starting it's own
filesystem search of the given paths given for files and folders etc...
...that "find" reads the list of input files from stdin or file.

Fantasy commandline:

$ find --files-from=input.txt -maxdepth 3 -type f -executable -ls

I just gave some dumb example from the top of my head.

In other words: "find" reads the files (and dirs) from input.txt (without
scanning the filesystem!) and then *further* narrows them down by it's own
options/directives, such as "-maxdepth 3" (relative from it's current working
directory) and "-type f" and "-executable" and so forth.

Expected result: "find" prints in "-ls" (ls -dils) format all 1) regular files
2) that are at maximum 3 levels of depth starting from the CWD, and 3) are
executable, but NOT from all files in the filesystem, starting from the CWD,
and instead starting only from the files in the input list (input.txt).

More examples:

$  rg --files | find -c -name "*.c" -newer reference.c -used 7 -ls

This example reads files from ripgrep, which provides an already narrowed down
scope of files in the filesystem that ignored SCM repositories and hidden
files and such, and the result is further narrowed down by "find" specific
syntax and options. In this case, any files output from "rg --files" are read
by find via "-c" option (same as "--files-from -", read from stdin), if they
are newer than "reference.c" and were accessed in the last 7 days since their
last status change, then output that further narrowed list of files in "-ls"
format.

Mind you, I can do "most" of those things using regular shell or "test"
constructs, but not all.

I think that "find" has a very powerful set of tests and the killer feature is
the way you can combine them in a compact sense.

$ find --files-from=input.txt -type f -executable -newer reference.c -ls

Above command unquestionably easier to do for most experienced find users
than:

$ while IFS=$'\n' read file; do
> [[ -f "${file}" -a -x "${file}" -a "${file}" -nt "reference.c" ]] && ls
-dils "${file}"
> done < input.txt

You could think of more complex examples, where the advantages of selection
and action via "find" directives (options/tests) is far more powerful,
precise, compact and easier to understand than what would be the equivalent of
an arbitrarily complex shell script using standard "test" facilities.

"find" is, in fact, superior to "test" in many ways. It just offers far more
possibilities for tests.

I was wondering what other users think about making use of "find's" directives
on a given list of files, instead of the current behavior of recursing into
the filesystem or given paths.

Please discuss/consider and thank you in advance.





    _______________________________________________________

Reply to this item at:

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

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