PaoloFCantoni wrote:Thanx Mofi... Have you reported the problem already or should I?
I don't have reported it because I don't use Perl. In the past I have reported some general Perl problems, but nothing special like that. I tested today what the IDM developers have fixed in v12.20+1 from my reports and which bugs still exist. Some general Perl related bugs I reported with macro usage are fixed, but some Perl problems still exist.
Your Perl regex ReplInFiles could be also done with the UltraEdit or legacy Unix regex engine. Maybe you use one of the legacy engines as workaround.
ReplInFiles MatchCase RegExp Recursive Log ProjFiles "" "" "_^([A-Z0-9]+^)_^([~0-9A-Za-z_]^)"
ReplInFiles MatchCase RegExp Recursive Log ProjFiles "" "" "_([A-Z0-9]+)_([^0-9A-Za-z_])"
I have not really tested it with ReplInFiles, but I think it will work.
Note: This regex will not work for a target word which is at the end of the file without a line termination because no character after the target word.
And my test project file (exactly workspace) does not have files in subdirectories so I could not really test it, but I think the parameter Recursive
is not needed with ProjFiles
PaoloFCantoni wrote:The OutputWin was my mistaken attempt to keep a log of changes made...
No problem. I have detected and also reported some weeks (months?) ago that the macro recorder records the parameter OutputWin for ReplInFiles according to the current state of the Find In Files option "Results to Edit Window". The wrong recorded parameter OutputWin has no influence on the execution of the macro command ReplInFiles.
PaoloFCantoni wrote:I'm running a string of 10 (or so) ReplInFiles accross an entire project of 15 folder trees and several hundred files. I need to keep a log of the changes the macro made. It looks as though I can't retain a "longitudinal" log using ReplInFiles. So... Should I preface each ReplInFiles with the equivalent FindInFiles placing the result to new window for each "scan"?
Yes, the Log option of ReplInFiles reports in the output window only which files are searched for and how many changes are done in any file. It does not report the lines with the changes. The reason is quite simply: Replace In Files can be used also for block replaces or line termination conversions or to change bytes in real binary files as I do sometimes.
So you better run first the 10 (or so) FindInFiles without parameter OutputWin to get a log file with the lines with the strings which are hopefully replaced then by the ReplInFiles commands.