How to merge two text files?

[jaclaz]

The script stops after doing DIR if the directory is empty ("File Not Found").

Well, the idea was to give you the hints, not doing your tests....

What happens with:

FOR /F %%I IN ('^>nul DIR/A-D/B HFMER 2^>^&1') DO (

jaclaz

[tomasz86]

"^" was necessary

Doing like this is enough for my script

FOR /F %%I IN ('DIR/A-D/B HFMER ^2^>NUL')

Thank you once again.

[tomasz86]

Using COPY /B serves no purpose when used in that manner, in fact it is the default mode when copying single files.

I'm asking about this once again as I'd like to be sure.

If COPY/B has no use when copying single files, when do you actually have to use it?

Edited March 3, 2013 by tomasz86

[Yzöwl]

Basically, you should only require to use it when merging files into one.

Read more about it, (Notes: 3.).

[jaclaz]

Basically, you should only require to use it when merging files into one.

Read more about it, (Notes: 3.).

Well, that seems to apply to MS-DOS 7.

The MS resource seen before:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/copy.mspx?mfr=true

is about XP.

The one I cited seems like being NT4 and 2K "oriented":

http://ss64.com/nt/copy.html

(though as said it is possible that is alltogether "wrong", it does look similar to an actual output of a "COPY /?" )

Since it is not the first time that a "common" program syntax changes dramatically between one version of the OS and the other, it is still possible that NT4/2K behave differently.

I have found another "hits" for " /A : ASCII text file (default)":

http://www.bat-to-exe.com/batchcommands/copy.html

that seem like not coming from the same SS64 source.

@tomasz86

Why don't you simply try with a few files?

jaclaz

[Yzöwl]

Well, that seems to apply to MS-DOS 7.

The MS resource seen before:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/copy.mspx?mfr=true

is about XP.

The one I cited seems like being NT4 and 2K "oriented":

http://ss64.com/nt/copy.html

(though as said it is possible that is alltogether "wrong", it does look similar to an actual output of a "COPY /?" )

Since it is not the first time that a "common" program syntax changes dramatically between one version of the OS and the other, it is still possible that NT4/2K behave differently.

I have found another "hits" for " /A : ASCII text file (default)":

http://www.bat-to-exe.com/batchcommands/copy.html

that seem like not coming from the same SS64 source.

@tomasz86

Why don't you simply try with a few files?

jaclaz

Summary from Windows XP and DOS 7 (above)

In Windows XP

/b is the default value for copy, unless copy combines files.

In Dos 7

By default:

When copying files from one location to another, COPY assumes binary mode;

When concatenating files, COPY assumes ASCII mode;

They dont appear to be contradictory so why would NT4 2000 have changed in between them

[jaclaz]

They dont appear to be contradictory so why would NT4 2000 have changed in between them

It is a possibility, only trying to find a reason for the mentioned "/A (default)", BTW DOS 7 comes AFTER NT and before 2K.

jaclaz

[Yzöwl]

Typing error, NT5 2000

[tomasz86]

I managed to get the UpdateInis working but is there any way to prevent moving the edited section to the end of the file?

I change some entries under [Version] and after that the whole [Version] section is moved to the end of the update.inf file.

[jaclaz]

I managed to get the UpdateInis working but is there any way to prevent moving the edited section to the end of the file?

I change some entries under [Version] and after that the whole [Version] section is moved to the end of the update.inf file.

And again, no crystall ball available at the moment.

Standard litany:

http://homepages.tesco.net/J.deBoynePollard/FGA/problem-report-standard-litany.html

Additionally post the actual file that gives you problems (before and after the whatever steps you took into changing it).

jaclaz

[tomasz86]

http://www.mediafire.com/file/1p82vz13vomc0g9/updateinis.7z

update-org - the original update.inf

updateinis.inf - the Update INIs file

update.inf - after running Update INIs (rundll32.exe advpack.dll,LaunchINFSection updateinis.inf,,1)

Edited August 25, 2011 by tomasz86

[jaclaz]

http://www.mediafire.com/file/1p82vz13vomc0g9/updateinis.7z

update-org - the original update.inf

updateinis.inf - the Update INIs file

update.inf - after running Update INIs (rundll32.exe advpack.dll,LaunchINFSection updateinis.inf,,1)

Are you talking of these?

[update.Version]

"D:\HFMER\SP\update.inf","Version","MaxNtServicePackVersion=1024","MaxNtServicePackVersion=1560"

"D:\HFMER\SP\update.inf","Version","ThisServicePackVersion=1024","ThisServicePackVersion=1560"

"D:\HFMER\SP\update.inf","Version",,"ThisServicePackBuild=1"

What if you use INSTEAD "Update .ini Fields sections (UpdateIniFields)":

http://technet.microsoft.com/en-us/library/dd346763.aspx

jaclaz

[tomasz86]

I can't get it to work with UpdateIniFields. I've tried many different combinations but the best result I can get is:

UpdateIniFields

[DefaultInstall]
UpdateIniFields=Update.Version

[Update.Version]
"D:\HFMER\SP\update.inf","Version","MaxNtServicePackVersion","1024","1536"

Result

MaxNtServicePackVersion=MaxNtServicePackVersion= 1536

[jaclaz]

I can't get it to work with UpdateIniFields. I've tried many different combinations but the best result I can get is:

You are right, it simply does not work , and anyway re-orders the sections as well.

jaclaz

[tomasz86]

I guess I'll have to stick to Update Inis as reordering the sections in this case doesn't have any influence on how update.inf works... and what's more important is that Update Inis seems to work smoothly.