I guess that option is not used in games, so DOSBox developers won't put it in their to-do list.

Also, have you tried running 4DOS in DOSBox? As a command.com replacement, the copy command may work as you wish.

Thanks for the suggestion. I'll take a look at 4DOS.

It does work in DOSBox. There are a number of games that shipped on floppy that had resources split to span across several disks. The original installers concatenate these resources and I can confirm that this works in DOSBox.

I expect that it's possible that your installation concatenation was done using some other method than the COPY command. I certainly couldn't get the simple example shown in my first message to work for me.

Try this one. It should work in DOSBox. I've just tried "copy file1.txt + file2.txt file3.txt" and it successfully created file3.txt.

Dosbox is not meant to be a substitute of dos (a lot of commands and functions are missing). Dosbox mission is to successfully run games (primarily) and applications (secondarily).
This is why concatenation is now available.

thought we supported copy a+b c
Don't know about spaces between the parts though.

Please note that this guy uses x+y+z instead of x+y z which may indeed not work in dosbox (though no idea what that does in msdos).

In MSDOS, copying files like "copy file1+file2+file3" puts all parts in file1. I think this is because the destination filename is optional in DOS, and defaults to the source filename if not specified. For example "copy file1" results in the error "File cannot be copied onto itself". In DOSBox, "copy file1" causes file1 to be truncated to zero length. Anyway, it's probably best to always use a destination filename in DOSBox.

The syntax that the old Sierra installers used was

1copy resource.000 + %2:resource.001  
2copy resource.000 + %2:resource.002  
3copy resource.000 + %2:resource.003  
4copy resource.000 + %2:resource.004  
5copy resource.000 + %2:resource.005

etc., with file checks in between each copy command as each part was on a different disk. This does work in DOSBox.

"copy file1 + file2" or "copy file1 +file2" results in "Illegal Path." error and file1 truncated to zero length.
"copy file1+ file2" or "copy file1+file2" works OK.
So, DOSBox doesn't like a space before the plus sign.
The OP's and collector's example have spaces on both sides of the plus sign, and that does not work in my tests.

The above example comes from the install script file for QfG3. The resource files do get concatenated by the Sierra installer. The "%2:" is a variable for the source disk, of course and the resource.000 is already in the install folder. It doesn't seem likely that having the two files in different locations should make a difference.

here is the entirety of the script. It is used by the Sierra installer and is not a stand alone batch file.

1clear
2space %1: 7500	NoSpace
3godir %1:%4	CantCreate
4
5echo Copying Drivers ...
6copy %2:version 
7copy %2:sierra.exe
8copy %2:*.drv 
9copy %2:interp.* 
10copy %2:install.* 
11copy %2:*.map  
12copy %2:read*.*
13
14copy %2:resource.msg
15echo %3 > resource.cfg
16
17clear
18echo Processing Audio Files ...
19%2:audio.exe >nul
20if exist %2:*.fon copy %2:*.fon 
21if exist %2:*.hep copy %2:*.hep 
22if exist %2:*.msg	copy %2:*.msg 
23if exist %2:*.pal	copy %2:*.pal 
24if exist %2:*.scr copy %2:*.scr 
25if exist %2:*.tex	copy %2:*.tex 
26if exist %2:*.txt	copy %2:*.txt 
27if exist %2:*.voc	copy %2:*.voc 
28if exist %2:*.p56	copy %2:*.p56 
29if exist %2:*.v56	copy %2:*.v56 
30
31if exist resource.000 del resource.000
32clear
33copy resource.000 + %2:resource.001  
34
35clear
36exists %2:resource.002 Please insert the disk labeled "Disk 2" in drive %2:.
37copy resource.000 + %2:resource.002  
38
39clear
40exists %2:resource.003 Please insert the disk labeled "Disk 3" in drive %2:.
41copy resource.000 + %2:resource.003  
42
43clear
44exists %2:resource.004 Please insert the disk labeled "Disk 4" in drive %2:.
45copy resource.000 + %2:resource.004  
46
47clear
48exists %2:resource.005 Please insert the disk labeled "Disk 5" in drive %2:.
49copy resource.000 + %2:resource.005  
50
51clear
52echo
53echo To play Quest for Glory III now:
54echo   Type SIERRA [ENTER]
55echo
56echo To play later:
57echo 	 From the directory of %1:%4,
58echo   and type SIERRA [ENTER]
59echo
60

61pause
62goto Exit2
63
64
65:NoSpace
66clear
67echo
68echo You do not have enough disk space on %1
69echo to install Quest for Glory III!
70echo 7.5 megabytes of hard disk space are required.
71echo
72pause
73
74:Exit2
75end
76
77:CantCreate
78alert Cannot create directory %1:%4.
79end

This does work in DOSBox and the resources are successfully joined.

Going by debug log messages, the QFG3 installer does not use its script to execute DOS commands. Rather, it appears to interpret the script and perform the necessary file operations itself.

1 226858069: FILES:file open command 0 file A:resource.001
2 226858251: FILES:file create attributes 0 file resource.000
3 226858697: DOSMISC:DOS:57:Set File Date Time Faked
4 226896610: FILES:file open command 0 file A:resource.002
5 226896816: FILES:file open command 1 file resource.000
6 226904533: DOSMISC:DOS:57:Set File Date Time Faked
7 226942464: FILES:file open command 0 file A:resource.003
8 226942670: FILES:file open command 1 file resource.000
9 226950387: DOSMISC:DOS:57:Set File Date Time Faked
10 226988300: FILES:file open command 0 file A:resource.004
11 226988506: FILES:file open command 1 file resource.000
12 226996223: DOSMISC:DOS:57:Set File Date Time Faked
13 227034140: FILES:file open command 0 file A:resource.005
14 227034346: FILES:file open command 1 file resource.000
15 227042063: DOSMISC:DOS:57:Set File Date Time Faked

The above is is only a portion of the log messages regarding resource files, but the rest of the log also shows that only file operations are taking place. There are no COPY commands being executed by the shell.

Thanks very much to ripsaw8080 for tracking down the exact cause of the problem I am experiencing with the Pyrosim pyrometallurgical simulator. I understand now that the DOSBox COPY command is indeed able to concatenate files, but is very fussy about the spaces in a command such as
COPY file1.txt + file2.txt + file3.txt
and results in the "Illegal Path." error and file1.txt being truncated to zero length, if there is a space before the plus sign. (It is worth remembering to avoid this for future use, but does not help with existing old software.)

Could I then please ask Qbix for a very specific request? Are you able to persuade DOSBox to ignore (like MS-DOS does) the space before the plus sign in the COPY command? I really hope you are able to make this change (that seems so small but probably isn't!), as that would make DOSBox even more useful to a whole lot of people.

Thanks again for writing such a useful piece of code, and thanks also to people (like ripsaw8080) who are willing to spend their time solving problems for others.

ripsaw8080 wrote:

Going by debug log messages, the QFG3 installer does not use its script to execute DOS commands. Rather, it appears to interpret the script and perform the necessary file operations itself.

The above is is only a portion of the log messages regarding resource files, but the rest of the log also shows that only file operations are taking place. There are no COPY commands being executed by the shell.

I had assumed that the installer script (.SCR) was used by the Sierra installer (INSTALL.EXE) rather than just a substitute for a batch file. In any case, there still may be some games out there that use the MS-DOS commands via actual batch files for their installers. Might be a good reason to have DOSBox's COPY behave like that of real DOS.

The attached patch is my attempt at handling any number of spaces on either side of the plus sign when concatenating source files in the COPY command. The changes are fairly minimal, and I've tried it with every permutation I can think of.

Edit: ltrim was not needed in any condition, so uploaded slightly simplified version of patch.

Looking at ripsaw's patch... yeah, that looks like it does what is intended.

I suppose if I were writing things from scratch though, I might do things differently, but bleh, that's way more work, and would introduce a hojillion bugs...

I suppose, we might want to report an error if someone puts in "copy + file1.txt + file2.txt file3.txt" ... As is, it just ignores the first "+" (which is perfectly legitimate).

report an error if someone puts in "copy + file1.txt + file2.txt file3.txt" ... As is, it just ignores the first "+"

I'm guessing this example was not actually tested, because the leading plus without a preceding source file causes a "Required parameter missing." error, with or without the patch.

A trailing plus (e.g. "copy file1+file2+") results in no error, and the concatenation into file1 works, but "0 files copied" is reported; however, it does that without the patch as well. In short, there's nothing in the patch to deal with malformed arguments, so the behavior in those cases should remain the same for the most part.

I'm guessing this example was not actually tested, because the leading plus without a preceding source file causes a "Required parameter missing." error, with or without the patch.

Ah yes... I see now, the error is caught later in the function... I was looking at catching the error as early as possible, but rather it just checks after collecting all of the sources to see if the first one is an empty filename... hm...

One can however fall through that check and get copy to try and open the filename "" by using: "copy file1.txt+ + file2.txt file3.txt" (This is however caught as an "Illegal Path" error.)

So, yeah, none of this really matters unless one is concerned about throwing the "correct" errors, which really isn't the goal of DOSBox anyways...