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
