Mail Archives: djgpp/2001/03/25/10:48:05
David Graff <graff AT unagi DOT cis DOT upenn DOT edu> wrote:
[...]
> __file_tree_walk( base_path, filter_func );
> ...
> int filter_func( const char *fspec, const struct ffblk *ff )
> {
> /* if fspec refers to a data file, and the contents of this file meet
> * certain conditions, come up with a modified copy of fspec, and use this
> * new name to create a new output file in the same directory as fspec;
> * pass the contents of fspec to the new file (with some modifications),
> * then close both files
> */
> }
For this type of usage, __file_tree_walk() may not be the correct
concept. At least not in the way you use it. You could return it to
'expected' behaviour by having the filter function store the set of
files that do have to be modified, by full pathname, and operate on
the stored list only after the file tree walking has finished.
The difference is the same that exists between the 'find' idioms:
find . -type f -name 'foo*.dat' -exec operation {} \;
and
find . -type f -name 'foo*.dat' | xargs operation
Whenever 'operation' causes modifications to the files and directories
visited by the 'find', strange error messages will often stream out of
'find', despite some valiant efforts by the GNU find authors to detect
such modifications happening under its very feet.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -