tomasz86

How to merge two text files?

238 posts in this topic

#1 is expected behaviour.

#2 is strange, the "beautify.cmd" is the one that should revert the "§#§" and "§##§" to their original values.

::Restore changes made to make the .inf "batch compatible"

::Replace dummy string "§#§" with "=="
CALL :run_gsar :xa7:x23:xa7 :x3d:x3d

::Replace dummy string "§##§" with stoopid "&"
CALL :run_gsar :xa7:x23:x23:xa7 :x26

Are you sure you did run the beatify.cmd on the file?

Anyway I will try to reproduce and fix.

#3 should mean that somehow something was a-miss (a variable got a value of "space" or "tab") I will try to reproduce and fix :unsure:, the other quirks should be easily fixable

#4 yes, this was expected in case of duplicated sections, I'll put a check for such duplicated entries so that these sections will be merged when split :w00t: (I do know that is sounds queer, but it is how it will work ;))

jaclaz

0

Share this post


Link to post
Share on other sites

#2 is strange, the "beautify.cmd" is the one that should revert the "§#§" and "§##§" to their original values.

Are you sure you did run the beatify.cmd on the file?

You're right :) It was my fault. Everything O.K after running beautify.cmd.

#4 yes, this was expected in case of duplicated sections, I'll put a check for such duplicated entries so that these sections will be merged when split :w00t: (I do know that is sounds queer, but it is how it will work ;))

The problem is that (not 100% sure) this sourcedisksfiles has to be present twice in SP4's update.inf. The first one is related to the /integrate option if you want to integrate SP into W2K source CD and the other one is a normal sourcedisksfiles used when installing the update. I'm not sure but from analysing other SP's and Gurgelmeyer's USP5.1 I can say that both SourceDisksFiles are always present.

0

Share this post


Link to post
Share on other sites

The problem is that (not 100% sure) this sourcedisksfiles has to be present twice in SP4's update.inf. The first one is related to the /integrate option if you want to integrate SP into W2K source CD and the other one is a normal sourcedisksfiles used when installing the update. I'm not sure but from analysing other SP's and Gurgelmeyer's USP5.1 I can say that both SourceDisksFiles are always present.

I doubt it. :unsure:

There is nothing that can differentiate the two sections in themselves.

With the "Install XP from USB" consolidating Sections (with FEDIT) did not produce any unwanted effect, I can also mantain them "separate" by temporarily renaming them, but as I see it it would be philosophycally wrong.

I would keep the current (see attachment) consolidating approach and, once we will have solved the actual merging of two files, you will need to test if it works (as it should) with no duplicate sections.

Issue #3 was caused mainly by a question mark "?", which now is fixed.

The new version should work allright with the 4 mentioned .inf's, try with some other ones and let me know....

jaclaz

split_inf_2.zip

0

Share this post


Link to post
Share on other sites

I haven't got time to check everything thoroughly yet... but I think I found a bug ;)

1. "<=" and ">=" get changed to "< =" and "> =" respectively.

Operation = CheckFileVer, MSOERT2.DLL, >= , 6.0.0.0

becomes

Operation = CheckFileVer, MSOERT2.DLL, > = , 6.0.0.0

It doesn't work with update.exe. It must be written together.

2. I tried to merge the [sourceFilesDisks] in SP4 and indeed it doesn't seem to make any difference :)

3. Your script can already be used to merge files :> I tried some tricky thing but very simple :

copy *.inf update.inf

About 100 inf became a one big file (3000 kB). Next step was to process this file by your script. It took long time and the output file was > 250 MB ;) but the final file was sth I was looking for. Everything was merged under proper headings, the only problem was that everything was duplicated x 100 times. I used Notepad++'s sorting (TextFX) on each section separately and was able to remove duplicates this way. Still not perfect but it can save a lot of time. Your script is also very good at removing all the unnecessary spaces from an inf file.

4. I don't know why yet but the "echo is off." line is still present sometimes. Also when doing splitinf I have to press a key twice (somewhere in the middle) to make the script go on.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

1. other two "exception" that need to be taken into consideration in the batch :blushing:

2. Good. :)

3. Hmmm, don't think it is very productive, but the fact that the batch worked (though slowly) on a 250 Mb files is good news :thumbup , it means that there are no strange "overflows" or something the like

4. The "ECHO OFF" line is good (actually "bad" ;)) news, it means that the variable that was supposed to be echoed got a null value. I need to have the .inf on which this happens, as it marks the place where the problem is. (just like #3 in previous bug report)

If you use your "inappropriate" way depicted in #3 above, and, once you create the "original" BIG MERGED file you apply to it the splitinf.cmd, then go to the SPLIT_whatever directory you should be able to process the single section files, but I don't see how by sorting them you can know which one is the line relative to the single update .inf. :unsure:

jaclaz

0

Share this post


Link to post
Share on other sites

By doing the steps described in #3 I get sth like this

1) two updates.infs


[IE6.System32.Files]
BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL

[IE6.Cache.Files]
BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL

&


[IE6.System32.Files]
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

[IE6.Cache.Files]
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

2) copy *.inf update.inf


[IE6.System32.Files]
BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL

[IE6.Cache.Files]
BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL

[IE6.System32.Files]
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

[IE6.Cache.Files]
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

2) After your script:


[IE6.System32.Files]

BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL


[IE6.Cache.Files]

BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL


[IE6.System32.Files]

BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL


[IE6.Cache.Files]

BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

If you remove the second duplicated [iE6.System32.Files] & [iE6.Cache.Files] (and use Notepad++'s sorting if necessary) the file will be merged. Of course there may be some other work necessary if the file is complicated but still it works for me :) I can save time by using your script even now.

0

Share this post


Link to post
Share on other sites

If you remove the second duplicated [iE6.System32.Files] & [iE6.Cache.Files] (and use Notepad++'s sorting if necessary) the file will be merged. Of course there may be some other work necessary if the file is complicated but still it works for me :) I can save time by using your script even now.

Well, you can dedupe the [1ndex] by processing it with FEDIT.

Try the attached join_dedupe_inf.cmd instead of join_inf.cmd, I modified it a little bit to create (hopefully) a deduped [1NDEX] fie (actually called [2NDEX] ;)):

::BEGIN MODIFIED
ECHO [DUMMY_SECTION]>%Split_dir%[2NDEX]%Source%
FOR /F "skip=2 tokens=1 delims= " %%A IN ('FIND "[" %Split_dir%[1NDEX]%Source%') DO (
SET string=%%A
SET string=!string:[=!
SET string=!string:]=!
ECHO Processing %%A....
Fedit -f %Split_dir%[2NDEX]%Source% -add -once -create -l "dummy" -s "!string!"
Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "dummy" -s "!string!"
)
Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "[DUMMY_SECTION]"
ECHO.
ECHO.
ECHO TYPE %Split_dir%[2NDEX]%Source%
ECHO.
TYPE %Split_dir%[2NDEX]%Source%
ECHO.
FOR /F %%A in (%Split_dir%[2NDEX]%Source%) DO (
ECHO COPY /B %Work%+%Split_dir%%%A%Source% %Work%
COPY /B %Work%+%Split_dir%%%A%Source% %Work%
)
::END MODIFIED

But the problem I see in "real life" is the order in which you copy together the single .inf files. :unsure:

Wouldn't it be possible that a newer update line is overwritten by an older one (if by chnace a file is copied in the "wrong" order)?

I will add the <= and >= provision. :)

jaclaz

join_dedupe_inf.zip

0

Share this post


Link to post
Share on other sites

Of course there's a chance, I highlighted that fact towards the beginning of this Topic.

Even simple things such as this are a problem:

[Version]

Signature = "$Windows NT$"

LanguageType = %LangTypeValue%

NtBuildToUpdate = 2195

NtMajorVersionToUpdate = 5

NtMinorVersionToUpdate = 0

MaxNtBuildToUpdate = 2195

MaxNtMajorVersionToUpdate = 5

MaxNtMinorVersionToUpdate = 0

MinNtServicePackVersion = 1024

MinNtServicePackVersion = 768

MaxNtServicePackVersion = 1024

MaxNtServicePackVersion = 1536

ThisServicePackVersion = 1280

ThisServicePackVersion = 1024

CatalogFile = %SP_CAT_NAME%.cat

CatalogFile = sp4.cat

0

Share this post


Link to post
Share on other sites

Yzöwl,

but these are simple things I can easily sort manually :)

jaclaz,

fantastic work :thumbup The new split_dedupe_inf only removes the duplicated sections, not duplicates in the same section. Am I right?

"Echo is off." in this file.

Is "==" also in exlusions?

like this one

Operation = CheckFileVer, atapi.sys, ==, 5.0.2195.5762

I'll do more tests tomorrow.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

Of course there's a chance, I highlighted that fact towards the beginning of this Topic.

Even simple things such as this are a problem:[

Exactly :thumbup

Yzöwl,

but these are simple things I can easily sort manually :)

I may be wrong, but the actual fun in using batches to automate things is to actually automate them. :whistle:

fantastic work :thumbup The new split_dedupe_inf only removes the duplicated sections, not duplicates in the same section. Am I right?

Actually it simply "dedupes" the index of sections, so that each "split" file is only processed once.

"Echo is off." in this file.

I'll check. Checked, they are stoopid [TAB]'s. Will add.

Is "==" also in exlusions?

like this one

Operation = CheckFileVer, atapi.sys, ==, 5.0.2195.5762

Yes:

::Final adjustments to be run ONLY once
::run Once
::Replace "==" with a dummy string "§#§"
CALL :run_gsar :x3d:x3d :xa7:x23:xa7

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Yzöwl,

but these are simple things I can easily sort manually :)

No they are not, basically there are lines in each inf which are pertinent only to that inf. Once you merge them into one you are unable to track information between each file. When the inf is run it will use the value last recorded for a particular piece of data. If you run a line which was intended only for minimum service pack version 1024 against a machine at 768 then you can do untold damage to their system.

I'm aware that the exact case above is relatively simple to fix manually but that is only based on the first section at the top of each of the four files you've linked to, what about every other section and every other update.

I'm fairly certain that the work needed to do what you want in a scripting language, (and probably a real programming language), will be greater than simply running the updates in sequence as they are now.

It appears that you wish to not do that so that you can be the champion of a new unofficial service pack project; But at what cost, especially to those who have done all of the donkey work for you!

BTW, I've attached a copy of the resulting file from merging the four samples you provided using my own batch only script. There were errors so the output is incorrect but it was a simple test in order to provide some output for the purposes of this post. I've no real intention of fixing these errors right now. What I'd like from you is an explanation of how you intend to ensure that information from one original file will not overwrite or break that of another section.

MERGED.rar

Edited by Yzöwl
Attachment and info added
0

Share this post


Link to post
Share on other sites

Yzöwl,

but these are simple things I can easily sort manually :)

No they are not, basically there are lines in each inf which are pertinent only to that inf. Once you merge them into one you are unable to track information between each file. When the inf is run it will use the value last recorded for a particular piece of data. If you run a line which was intended only for minimum service pack version 1024 against a machine at 768 then you can do untold damage to their system.

In such case only 1024 must be used to prevent problems. What I do is to check every section manually and see if there is something wrong with it. Once you've got accustomed to them it's relatively easy to know instantly which lines are correct and which ones are not. Also when running the update.exe it checks if the .inf file is correct and reports an error if there are problems.

Also one more info: the order of lines in each section doesn't matter at all. I've already checked that. They can be sorted alphabetically.

It appears that you wish to not do that so that you can be the champion of a new unofficial service pack project; But at what cost, especially to those who have done all of the donkey work for you!

I don't really understand why you're writing something like this... especially considering that I've already made HBR Mini Rollup & IE / OE Mini Rollup (100% manual work by myself) and UR2 for Win2k (107 updates merged; used HFSLIP's script for merging files and manually merged update.infs).

I have enough knowledge about update.infs to merge them myself manually but it requries a lot of time and work which could be simplified using such a script like this one created by jaclaz. I don't know how to write such a script myself so I asked for help here. Is there anything wrong about it? :huh:

jaclaz,

there is one big problem when merging something like this

    HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%",,,"%COMPID%"
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","IsInstalled",0x10001,01,00,00,00
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","Version",,"%VERSION%"
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","ComponentID",,"%COMPID%"
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed",0x10001,1
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Comments",0,%SP_TITLE%
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Backup Dir",0,""
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Fix Description",0,%SP_TITLE%
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed By",0,""
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed On",0,""
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"IE Service Pack",0x10001,%SERVICE_PACK_NUMBER%
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Service Pack",0x10001,%OS_SERVICE_PACK_NUMBER%
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Valid",0x10001,1
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"Flags",0,""
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"New File",0,""
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"New Link Date",0,""
HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"Old Link Date",0,""
HKLM,SOFTWARE\Microsoft\Updates\%SourceDiskName%\SP%SERVICE_PACK_NUMBER%\%SP_SHORT_TITLE%,"Description",,%SP_TITLE%
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%SP_SHORT_TITLE%,"DisplayIcon",,"%11%\msiexec.exe"

%(...)% are defined in [strings]

    STR_PROGRAMF_DIR    = "Program Files"
STR_COMMON_DIR = "Common Files"
STR_MAILNEWS_DIR = "Outlook Express"
STR_SHARED_DIR = "Microsoft Shared"
STR_MSINFO_DIR = "MSInfo"
STR_VGX_DIR = "VGX"
SourceDiskName = "Internet Explorer 5.01"
STR_SYSTEM_DIR = "Common Files\System"
LangTypeValue =0x09
LCID =0409
W32ID =0x09
Compid ="KB938127"
Version ="5,0,3854,2500"
Guid ={90b0bef8-22d6-40a8-92c8-155434fc112f}
SP_SHORT_TITLE ="KB938127-IE501SP4-20070626.120000"
SP_SHORT_TITLE_DISPLAY ="KB938127"
HELPLINK ="http://support.microsoft.com/?kbid=938127"
BUILDTIMESTAMP =20070626.120000
SERVICE_PACK_NUMBER =4
OS_SERVICE_PACK_NUMBER =5
IeRegKey ="Software\Microsoft\Windows\CurrentVersion\App Paths\iexplore.exe"
URLInfoAbout ="http://support.microsoft.com"
ServicePackSourceFiles="Windows 2000 Hotfix Source Files"
SP_TITLE="Windows 2000 Hotfix - KB938127"

Almost all Win2k updates use such a structure but if you merge them the data is lost. If I wanted to process updates by your script I would have to change manually each updates' data to sth like before merging them:

 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Backup Dir",0,""
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Comments",0,"Windows 2000 Hotfix - KB938127"
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Fix Description",0,"Windows 2000 Hotfix - KB938127"
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","IE Service Pack",0x10001,4
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Installed By",0,""
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Installed On",0,""
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Installed",0x10001,1
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Service Pack",0x10001,5
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Valid",0x10001,1
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","Flags",0,""
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","New File",0,""
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","New Link Date",0,""
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","Old Link Date",0,""

Is it even possible to do such a thing automatically or would it require too much work?

Edited by tomasz86
0

Share this post


Link to post
Share on other sites
I don't really understand why you're writing something like this... especially considering that I've already made HBR Mini Rollup & IE / OE Mini Rollup (100% manual work by myself) and UR2 for Win2k (107 updates merged; used HFSLIP's script for merging files and manually merged update.infs).

I have enough knowledge about update.infs to merge them myself manually but it requries a lot of time and work which could be simplified using such a script like this one created by jaclaz. I don't know how to write such a script myself so I asked for help here. Is there anything wrong about it? :huh:

Of course there is!

The project is basically the script, but you've not done it, someone else has, at the moment it's jaclaz's work

The same as your roll up script which was in the majority a copy of the work done by others on the HFSLIP project.

0

Share this post


Link to post
Share on other sites

I didn't use any script when making HBR Mini Rollup & IE / OE Mini Rollup.

As for HFSLIP:

You are free

(1) to Share - to copy, distribute and transmit HFSLIP (the work)

(2) to Remix - to adapt the work

Under the following conditions:

(1) Attribution. You must attribute the work in the manner specified by the

author or licensor (but not in any way that suggests that they endorse

you or your use of the work).

(2) Noncommercial. You may not use this work for commercial purposes.

(3) Share Alike. If you alter, transform, or build upon this work, you may

distribute the resulting work only under the same or similar license to

this one.

In the very beginning (in this topic) I stated that the script is a part of the HFSLIP's script. I didn't write anywhere that it was my work.

TO prevent further problems:

Jaclaz, is it O.K to use your script when merging updates in order to make update rollups for Win2k?

0

Share this post


Link to post
Share on other sites

Jaclaz, is it O.K to use your script when merging updates in order to make update rollups for Win2k?

As long as you comply with my Careware License ;), yes, of course :):

http://jaclaz.altervista.org/Projects/careware.html

but - as said - at the moment we are very little beyond the "proof of concept" stage.

Can you assemble together a "fake" update .inf file with all the lines that you find needing manual correction (i.e. the ones that result as "different" in the re-joined file?

This way I can have all in one source the "problematic parts" and test the batches more easily....

IN other words, if you could manually assemble a fake "difficult" file, it will be faster for me.

jaclaz

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.