Issues importing 50,000 line .REG file

[UbuntuSupahFly]

When importing large .REG files into WINE, is there a way to make it report the line number of a problem entry? I have a 50,000 line .REG file that goes along with my Adobe CS4 package that was generated using a 3rd party oversight tool which tracked all the data written to the original WinXP registry by the Adobe Installer, but the file has some formatting issues due to a bug in the original software that has yet to be patched.

What I wish to do is have WINE's regedit report on the command line when there's a problem (which it does) along with the line number of the offending entry so I can fix it manually. Hundreds of lines of "Warning! Unrecognized escape sequence:" doesn't really help.

[spoon0042]

I don't know what your programming background is but from a brief look at it that warning is apparently coming from progams/regedit/regproc.c in REGPROC_unescape_string. That in turn is only called in two places, it should be possible to tweak / hack it to do what you describe. I'm wondering though, is that the only message you get? And even if it is it should be printing the unrecognized character so you should be able to search for that in vi or whatever. Ultimately it may be possible to fix your problem with a perl one-liner.

[UbuntuSupahFly]

Well, I have a little Windows tool that checks the validity of .REG files for syntax problems which I found after extensive searching on Google, but the tool says the file is clean when I run it natively on my XP machine. When I load it in WordPad on XP, it complains about it using Unix LF instead of Windows CRLF, but that's never bothered WINE's RegEdit before because the file itself is UTF-8.

When importing this exaustive .REG file, yes, that is the only error I am getting.

My background in programming covers minor "personal convenience" projects in BASH with a light dusting of Visual Basic 5 and some COBOL from my college days, although, if I knew where to make the edits, I can add a line that effectively says "Print the error and the line number".

If the file was smaller, it probably wouldn't be an issue, but this thing is 5 MB (47,351 lines) so finding 100 "\P" that aren't properly escaped manually would be virtually impossible. Much like determining the mass, in micrograms, of a black hole, relative to normal space.

Could the problem simply be that the file is UTF-8 instead of UNICODE? There are some extended characters for specific non-English language settings for various Adobe facets of CS4 in there, but it's not complaining about them, it's complaining about various standard upper/lower case letters.

[UbuntuSupahFly]

It uses an array that isn't defined by line numbers, but I think I can tweak this so it prints the entire offending line, and not just the offending character, which, while not as good as a line number is still better than what it does. Unless I'm wrong. Of course it will take several hours to compile my changes, so I won't know until I run my version.

Original (lines 280 - 284):

Code: Select all

            default:
                fprintf(stderr,"Warning! Unrecognized escape sequence: \\%c'\n",
                        str[str_idx]);
                str[val_idx] = str[str_idx];
                break;

My revisions (lines 280 - 284):

Code: Select all

            default:
                fprintf(stderr,"Warning! Unrecognized escape sequence: \\%c'\n",
                        str);
                str[val_idx] = str[str_idx];
                break;

[UbuntuSupahFly]

Well, I'm not sure it's any better. With the change I made, I get this instead:

Code: Select all

fixme:msvcrt:pf_printf_a multibyte characters printing not supported
Warning! Unrecognized escape sequence: \:'

However, when I run the GUI, it imported the entire 50,000 lines. I was able to verify the keys were all added, and there was no error report. Perhaps it's just a superficial thing, like a non-fatal complaint?

[spoon0042]

Pretty sure you need to change %c to %s if you want the whole string. But if it works, don't bother. I did look at it again, and what it's doing is ignoring the backslash if it's not \r or \n or \0 and just copying the following character (and throwing that warning). If all that program was doing was inserting spurious backslash escapes, you should be fine.

[UbuntuSupahFly]

Actually, the issue with the Win32 software was two-fold. One was not properly escaping pathnames. Things like C:\Program Files\Adobe\Something-Or-Other instead of C:\\Program Files\\Adobe\\Something-Or-Other, and the other was some keys being escaped (for example [HKEY_LOCAL_MACHINE\Software\\Adobe\\PDF Admin Service\\...]) so I couldn't just aribitrarily search and replace in gEdit because not all \\Adobe\\ entries (for example) were wrong.

I went through line by line manually, fixing everything myself, and tried from the command line to import the .REG and it kept spitting out "Escape Errors", so I assumed there was still some problem with the .REG file. Now however, it looks as if there never was a problem after I manually fixed the file, and all I had to do was import from the GUI.

I have made the change from %c to %s, however, just out of curiosity, and as I type this, am rerunning MAKE, as I am curious to see the results of attempting to import this .REG into a clean prefix. Syntactically, the file itself is sound. Double-checkedon Win32 again. Once MAKE finishes, I'll be in business.

Thanks for all your help!