>Hi Charles,
>
> It's probably good to run all the proposed approaches and compare the speed. I guess Ed's algorithm and FoxTools reduce() function should be the winners, but somebody has to check. Let original poster make these comparings and define his choice :)
>

I think he ruled out REDUCE() because he needed to strip both CR and LF occurances, and did not want to use any components from the WSH, without considering what benefits are derived from having the WSH as a base requirement of the target system. I see things differently AFA what I spec for client requirements, not just from the standpoint of the innards of the app itself, but also from the general utility of the WSH as a lightweight installer and programmable extension to the Windows environment in general, and I like the versatility and ease of use of the COM objects that accompany it - I can do file system handling, basic Shell API functionality, basic network and printer services, regular expressions and more cross-platform in a consistent fashion, and scripting gives me the extended functionality I've always wanted for things like batch files, including the choice of several scripting languages, the ability to create and run scripts as text on the fly, and the ability to integrate COM services in the script environment.

There is a catch - the WSH has to be installed; it's freely available and redistributable, but it's an added factor, and there are a few people with elderly and not patched to current level Win9x and WinNT installs, or with some foreign-language retail releases of Win95, that need to update their OS - but they need the same basic updates to get a stable, reliable and compliant system IAC. The COM objects add a memory and disk footprint to each target machine. The COM interface is in many cases slower than equivalent native language equivalents, if for no other reason than the interaction between app and COM objects adds layers of translation and data exchange. Much of the same functionality is available to the programmer through the API interfaces, as well as a ton of stuff not surfaced via COM, which doesn't fully remove the burden of understanding API interaction for the VFP developer.

On the whole, I see the benefits far outweigh the costs, but I'm not afraid of the underpinnings of installation, and made a decision to not depend on the services that ship with VFP except for the tasks they do well - installing the necessary VFP runtime components under the direction and supervision of a more potent tool, and then leverage WSH and add-ons like SDT to manage ongoing installation maintenance/upgrade issues. WSH is not a panacea for all issues, but where it works, it's clean, easy and potent.