Re: find -f -, please?

[Eric Blake]

On 02/15/2016 02:44 PM, Marc Chantreux wrote:
> 
> because the line exceed the max size of a command so i wrote
> 
>     a-very-long-list-of-files |
>         xargs -IX find X -prune -type f -name '*scm'
> 
> which works fine regardless the fact the find command was started for
> all single file (-I implies -L1).

It would also be possible to do this with fewer processes spawned,
insofar as none of the output of a-very-long-list-of-files can be
ambiguous with a find expression, by doing:

a-very-long-list-of-files |
  xargs sh -c 'find "$@" -prune -type f -name "*scm"' sh

> 
> I finally wrote
> 
>     a-very-long-list-of-files | perl -lnE 'print if -f && /[.]scm$/'
> 
> this isn't a problem on a BSD system as find has the wonderfull -f.
> According to http://netbsd.gw.com/cgi-bin/man-cgi?find+1+NetBSD-current
> 
>     -f  Specifies a file hierarchy for find to traverse.
>         File hierarchies may also be specified as the
>         operands immediately following the options.

Could you show the actual command line you envision writing with -f in
use?  I think you have confused two different feature requests, but
seeing your intended usage would make that easier to tell.

As far as I can tell, the BSD -f is mostly unnecessary fluff, but easy
to add.  That is, for an unambiguous name:

find -f foo expression

is identical to:

find foo expression

Meanwhile, if you want to start your search on a name that is ambiguous
with an expression element, you can use:

find -f -name expression

which can always be safely written as:

find ./-name expression

except that any output is now prefixed by ./ where with -f the extra ./
is not needed.  That is, BSD's -f is a way to say "treat the next
argument as a start point no matter what, even if without the -f it
would be ambiguous with the start of an expression".

> 
> It would be nice to get this feature into the gnu tools. I hope you like
> the idea.

The biggest argument in favor of adding the BSD -f feature is the fact
that it already exists in other implementations, thus adding it would
let GNU find still be a drop-in replacement for systems that were
relying on the non-free extension.  So yes, I'm interested in that idea.

> 
> I'm not a C expert but i get a naive overview of the source but my start
> should start with the patch at the end of the body then
> 
> * add the -f support in the code that read the flags
> * write a function process_traverse_path inspired by process_all_startpoints
>   that could be (pseudocode)
> 
>   foreach name in fflags
>     handle = name eq '-' ? stdin : fopen(name)
>     while getline handle, l
>         find(l)

Ouch. You're proposing a completely different behavior than what the BSD
-f performs.  That is NOT a good idea.  If we add -f, it should have
identical semantics to BSD.  If we want new semantics, it should not be
named -f.

Your proposal is the ability to teach find to read a list of filenames
from an input file, as if those files had been independently specified
on the command line.  Typical GNU spelling for such a feature already
exists: see, for example, 'du --files0-from=F'.  So we could easily use
the same code (assuming coreutils has shared du's --files0-from in
gnulib), as a similar starting point for findutils.  Whether we should
burn a short option letter is a different question (the long option
alone is all the more coreutils provided, and I already stated that we
will NOT burn '-f' for a meaning different from BSD's).

Your idea also has merit (let me supply a list of names as if they had
been separate command line arguments), particularly since I could
probably come up with some pathological case where a single find
invocation on ALL of those start points behaves differently than
concatenating the results of multiple find invocations on a subset of
the start points (not even that hard to envision such a scenario - it
seems like any expression including an '-exec {} +' would be an easy
place to start).  So I'm interested in that too.

> 
> so if it is correct and there is no maintainer to do the job, i'll be
> happy to try to submit a real live patch. 

Your patch will probably be non-trivial (it would need documentation and
testsuite additions, alongside the actual code), but it does sound
interesting.  If you are interested in pursuing copyright assignment to
the FSF, then we'd love to have you submit a patch.

At any rate, even if you don't supply a patch, you have proposed not
one, but two potentially useful enhancements.  It may be worth recording
them in the Savannah bug tracker so we don't forget about this mail.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature