Armed with the portable
search_all script from
Example 5-10, I was able to better pinpoint files to
be edited, every time I changed the book examples tree structure. At
least initially, I ran
search_all to pick out
suspicious files in one window, and edited each along the way by hand
in another window.
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 there are at least occasionally better things to do than manually start 74 editor sessions, I looked for a way to automatically run an editor on each suspicious file.
search_all 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 ...