Armed with the portable
search_all script from Example
7-10, I was able to better pinpoint files to be edited every
time I changed the book examples tree structure. At least initially,
in one window I ran
pick out suspicious files and edited each along the way by hand in
Pretty soon, though, this became tedious too. Manually typing filenames into editor commands is no fun, especially when the number of files to edit is large; the search for "Part2" shown earlier returned 74 files, for instance. Since I occasionally have better things to do than manually start 74 editor sessions, I looked for a way to automatically run an editor on each suspicious file.
simply prints results to the screen. Although that text could be
intercepted and parsed, a more direct approach that spawns edit
sessions during the search may be easier, but may require major
changes to the tree search script as currently coded. At this point,
two thoughts came to mind.
First, I knew it would be easier in the long run to be able to add features to a general directory searcher as external components, not by changing the original script. Because editing files was just one possible extension (what about automating text replacements too?), a more generic, customizable, and reusable search component seemed the way to go.
Second, after writing a few directory walking utilities, it became clear that I was rewriting the same sort of ...