[ILUG] find regex question

[Brian Foster]

  | Date: Tue, 18 Jun 2002 17:14:07 +0100
  | From: Padraig Brady <padraig at antefacto.com>
  |[ ... ]
  | yuk. Why put regex in find?
  | How about piping output of find to grep -E '[^/]*/[-0-9A-Z]{36}\.'

 because it's a powerful selection criteria?
 e.g., whilst you can pipe to `grep' to implement `And' conditions
 (e.g., is a directory And whose name matches the RE); it is much
 harder to do `Or' (e.g., is a directories Or whose name matches).
   having said that, `-exec sh -c "echo -E '{}' | grep -q ..." \;'
   could be used to do `Or' albeit at the cost of opaqueness (plus
   the usual newline-in-filename bugbear, see below) ....

 because it closes a security hole?
 files whose names contain a newline (e.g.) make writing a 100%
 reliable pipe-to-`grep' very difficult, perhaps impossible!
   whilst GNU `find' does have `-print0', I am unaware of any
   corresponding _input_ option for any `grep'.  hence, AFAIK,
   this hole cannot be closed when using pipe-to-`grep' ....

 because, continuing the above line-of-reasoning, other `find'
 options are also pointless, as they can also be done by piping
 the output of `find ... -print' to an appropriate command or
 (relatively simple) shell script.
 e.g., `-type' is pointless because it can be done by test(1):

     find DIR -type f -print

 is the same as (using GNU echo(1), and any Bourne-ish shell):

     find DIR -print | while read f; do [ -f "$f" ] && echo -E "$f"; done

 albeit that screws up on files named (e.g.) `-n' (plus the
 usual bugbear, files whose names contain a newline).

 the real issue here is that `find' is neither a filter nor a sink,
 but a source (of data).  active data sources tend to be complex
 (IMHO) since they, loosely speaking, create information.

 this is not a trivial thing to do.  consider, the simplest possible
 `find' is one which only does `-print'.   everything else is done
 by generally simple filters.  e.g., `grep' to filter on filenames,
 a mythical `perms' to filter on permissions, a mythical `times' to
 filter on a/m/ctimes, and so on ....  then, taking this reductionist
 plan to completion, a `-print'-only-`find' is itself unnecessary,
 as recursive directory listings can be done by other commands ....

 yet the `Or' and security problems (at least) would still exist.
 nothing has been solved, albeit a grand collection of new and
 perhaps useful tools/filters has been created.

cheers!
	-blf-
--
 Innovative, very experienced, Unix and      | Brian Foster    Dublin, Ireland
 Chorus (embedded RTOS) kernel internals     | e-mail: blf at utvinternet.ie
 expert looking for a new position ...       | mobile: (+353 or 0)86 854 9268
  For a résumé, contact me, or see my website  http://www.blf.utvinternet.ie

    Stop E$$o (ExxonMobile):  «Whatever you do, don't buy Esso --- they
     don't give a damn about global warming.»    http://www.stopesso.com
     Supported by Greenpeace, Friends of the Earth, and numerous others...