everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) (12/13/90)
OK, here's one for ya (and Microsoft). Lets assume that you have a program
called JUNK.COM in your current directory and it's 15385 bytes long (the
number doesn't matter). Now, do this:
COPY JUNK.* TEMPFILE
You shouldn't have any other files in the current directory that match JUNK.*
besides JUNK.COM. The result of this copy will be a file called TEMPFILE
with today's date and smaller than the original JUNK.COM (usually by a long
ways). What appears to be happening is that the COPY is being done as if
JUNK.COM was an ASCII file, and as soon as an EOF character (26) is encountered
the copy halts. The following will work:
COPY JUNK.* A:
COPY JUNK.* TEMPFILE.*
COPY JUNK.COM TEMPFILE
But NOT
COPY JUNK.* TEMPFILE
Seems like a bug to me.
Everett Kaser Hewlett-Packard Company
...hplabs!hp-pcd!everett work: (503) 750-3569 Corvallis, Oregon
everett%hpcvra@hplabs.hp.com home: (503) 928-5259 Albany, OregonRalf.Brown@B.GP.CS.CMU.EDU (12/13/90)
In article <31600012@hpcvra.cv.hp.com.CV.HP.COM>, everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) wrote: }OK, here's one for ya (and Microsoft). Lets assume that you have a program }called JUNK.COM in your current directory and it's 15385 bytes long (the }number doesn't matter). Now, do this: } COPY JUNK.* TEMPFILE }You shouldn't have any other files in the current directory that match JUNK.* }besides JUNK.COM. The result of this copy will be a file called TEMPFILE }with today's date and smaller than the original JUNK.COM (usually by a long }ways). What appears to be happening is that the COPY is being done as if }JUNK.COM was an ASCII file, and as soon as an EOF character (26) is encountered }the copy halts. The following will work: } COPY JUNK.* A: } COPY JUNK.* TEMPFILE.* } COPY JUNK.COM TEMPFILE }But NOT } COPY JUNK.* TEMPFILE }Seems like a bug to me. Nope. First, you can force a binary copy with the /B switch (before JUNK.*). Second, you want the copy to be in ASCII mode if you are concatenating text files which use the old ^Z end-of-file marker. An ASCII copy stops reading each source file when the ^Z is reached, then appends a single ^Z to the destination file after the copy completes. If it didn't act that way on concatenating files, you would have embedded ^Zs which would either confuse many programs or cause them to stop reading after the first file, thus effectively losing the rest of the files which were concatenated. In fact, the MSDOS 3.30 docs state: "When you are combining files, the default switch is always /a." -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
valley@uchicago (Doug Dougherty) (12/14/90)
everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) writes: >OK, here's one for ya (and Microsoft). Lets assume that you have a program >called JUNK.COM in your current directory and it's 15385 bytes long (the >number doesn't matter). Now, do this: > COPY JUNK.* TEMPFILE >You shouldn't have any other files in the current directory that match JUNK.* >besides JUNK.COM. The result of this copy will be a file called TEMPFILE >with today's date and smaller than the original JUNK.COM (usually by a long >ways). What appears to be happening is that the COPY is being done as if >JUNK.COM was an ASCII file, and as soon as an EOF character (26) is encountered >the copy halts. The following will work: > COPY JUNK.* A: > COPY JUNK.* TEMPFILE.* > COPY JUNK.COM TEMPFILE >But NOT > COPY JUNK.* TEMPFILE >Seems like a bug to me. >Everett Kaser Hewlett-Packard Company >...hplabs!hp-pcd!everett work: (503) 750-3569 Corvallis, Oregon >everett%hpcvra@hplabs.hp.com home: (503) 928-5259 Albany, Oregon The whole "ASCII file/^Z = EOF" thing is a bug, in my view. All copying should be in binary mode. Editors should not append ^Zs to files. Foo on the Norton Editor!
otto@tukki.jyu.fi (Otto J. Makela) (12/14/90)
In article <31600012@hpcvra.cv.hp.com.CV.HP.COM> everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) writes:
[description of problem, which boils down to the fact that JUNK.* are treated
as ASCII, not binary in the command COPY JUNK.* TEMPFILE]
This is a "feature" (n., bug or a quirk which has been documented).
It stems from the exceedingly weird method of concatenating files which is
supported by COPY (and alas, XCOPY), where you combine several files into
the target file by specifying several filenames OR wildcard pattern(s)
separated by pluses (+).
--
/* * * Otto J. Makela <otto@jyu.fi> * * * * * * * * * * * * * * * * * * */
/* Phone: +358 41 613 847, BBS: +358 41 211 562 (CCITT, Bell 24/12/300) */
/* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * * * * * */swh@hpcupt1.cup.hp.com (Steve Harrold) (12/14/90)
Re: Problems with COPY command
COPY commands of the form:
COPY file*.* targetfilename
COPY file1+file2+file3 targetfilename
combine (concatenate) files into one target file. Note carefully that
"targetfilename" is a filename NOT a directory name.
To quote from my HP Vectra MSDOS User's Reference,
"When COPY is used to copy a file, the source and target files
are treated as binary if no option is specified. When COPY
is used to combine files, the files are treated as ASCII if
no option is specified."
In your examples,
COPY JUNK.* A: is a file copy, assume binary
COPY JUNK.* TEMPFILE.* is a file copy, assume binary
COPY JUNK.COM TEMPFILE is a file copy, assume binary
COPY JUNK.* TEMPFILE is a file combine, assume ascii
A binary copy operation replicates the original file exactly, using the
directory filesize information. This is the default and corresponds to
the the most common way that people use the COPY command.
An ascii copy operation replicates each source file until the first
end-of-file marker (ctrl-Z) is encountered with the remainder of the file
being ignored. A ctrl-Z is placed at the end of the target file.
In short, the behaviour you've observed is CORRECT. Perhaps not intuitive,
but correct neverthless.
If you want to do what you've intended to do, execute:
COPY /B JUNK.* TEMPFILE
--
---------------------
Steve Harrold swh@hpda.hp.com
...hplabs!hpda!swh
HPG200/11
(408) 447-5580
---------------------kurtk@dino (Kurt Klingbeil) (12/14/90)
Everett Kaser Hewlett-Packard Company writes: > > The whole "ASCII file/^Z = EOF" thing is a bug, in my view. > All copying should be in binary mode. Editors should not append ^Zs > to files. Foo on the Norton Editor! Most certainly correct! As if it isn't stupid enough to have a two-character EOL (with every second editor handling lone CR's and LF's in arbitrary and nonsensical ways), a ^Z EOF is self-contradictory... and arguably even more stupid! The end of the file actually occurs AFTER the ^Z making the ^Z a JBEOF (just before). Then there are some systems which aren't satisfied with a single ^Z, but either deliberately pad the rest of the sector with them, or after each copy/edit operation add one more "End-Of-File", a form of audit trail... One (1) just has to shake one's head! <8-)
toma@tekgvs.LABS.TEK.COM (Tom Almy) (12/14/90)
In article <valley.661107643@gsbsun> valley@uchicago (Doug Dougherty) writes: >The whole "ASCII file/^Z = EOF" thing is a bug, in my view. >All copying should be in binary mode. Editors should not append ^Zs >to files. Foo on the Norton Editor! Not a bug, but a compatibility feature. MS/DOS was designed to be somewhat compatible with CP/M so that all the CP/M applications could be easily ported. In CP/M, files were always a multiple of 128 bytes so end of file was indicated by filling the end of the 128 byte sector with ^Z's. But this was years ago. There is no excuse for editors to append ^Z's now. In fact there is no excuse for any program not ported from CP/M (which is just about everything) to append ^Z's. BTW, the major, still existing in one form or another, applications ported: DBASE-II, WordStar, (Microsoft) Basic, SuperCalc, and Turbo Pascal. (I had them all!) Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
brad@huey.Jpl.Nasa.GOV (Brad Hines) (12/15/90)
In article <valley.661107643@gsbsun>, valley@uchicago (Doug Dougherty) writes: |> everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) writes: |> |> >OK, here's one for ya (and Microsoft). Lets assume that you have a program |> >called JUNK.COM in your current directory and it's 15385 bytes long (the |> >number doesn't matter). Now, do this: |> > COPY JUNK.* TEMPFILE |> >You shouldn't have any other files in the current directory that match JUNK.* |> >besides JUNK.COM. The result of this copy will be a file called TEMPFILE |> >with today's date and smaller than the original JUNK.COM (usually by a long |> >ways). What appears to be happening is that the COPY is being done as if |> >JUNK.COM was an ASCII file, and as soon as an EOF character (26) is encountered |> >the copy halts. The following will work: |> > COPY JUNK.* A: |> > COPY JUNK.* TEMPFILE.* |> > COPY JUNK.COM TEMPFILE |> >But NOT |> > COPY JUNK.* TEMPFILE |> >Seems like a bug to me. |> |> >Everett Kaser Hewlett-Packard Company |> >...hplabs!hp-pcd!everett work: (503) 750-3569 Corvallis, Oregon |> >everett%hpcvra@hplabs.hp.com home: (503) 928-5259 Albany, Oregon |> |> The whole "ASCII file/^Z = EOF" thing is a bug, in my view. |> All copying should be in binary mode. Editors should not append ^Zs |> to files. Foo on the Norton Editor! There was a blurb in the back of a recent PC Magazine about this. The problem is that COPY is running in ASCII mode in this case. Normally copy runs in binary mode, but when it sees something like COPY JUNK.* TEMPFILE it assumes (due to the *) that you are trying to append multiple text files (e.g., JUNK.TXT, JUNK.DOC, etc.) into a single output file and switches to ASCII mode. I believe that what you have to do in this case is explicitly specify the /B switch to get it to run in binary mode: COPY /B JUNK.* TEMPFILE -- Brad Hines Internet: brad@huey.jpl.nasa.gov JPL 169-214 4800 Oak Grove Drive Pasadena, CA 91107 USA 818-354-2465
einari@rhi.hi.is (Einar Indridason) (12/16/90)
In article <10758@jpl-devvax.JPL.NASA.GOV> brad@huey.Jpl.Nasa.GOV writes: >In article <valley.661107643@gsbsun>, valley@uchicago (Doug Dougherty) writes: >There was a blurb in the back of a recent PC Magazine about this. The problem is >that COPY is running in ASCII mode in this case. Normally copy runs in binary mode, >but when it sees something like > COPY JUNK.* TEMPFILE >it assumes (due to the *) that you are trying to append multiple text files (e.g., >JUNK.TXT, JUNK.DOC, etc.) into a single output file and switches to ASCII mode. >I believe that what you have to do in this case is explicitly specify the /B >switch to get it to run in binary mode: > COPY /B JUNK.* TEMPFILE Has anyone patched command.com to *stay* in binary mode *all* the time? (Solution: Get *NIX :-) -- Internet: einari@rhi.hi.is | "Just give me my command line and drag UUCP: ..!mcsun!isgate!rhi!einari | the GUIs to the waste basket!!!!" General Surgeons warning: Masking the 8th bit can seriously damage your brain!!
swh@hpcupt1.cup.hp.com (Steve Harrold) (12/18/90)
>>> Has anyone patched command.com to *stay* in binary mode *all* the time?
----------
Please don't. Else how will you concatenate ASCII files that each have
a Ctrl-Z at the end?valley@uchicago (Doug Dougherty) (12/19/90)
swh@hpcupt1.cup.hp.com (Steve Harrold) writes: >>>> Has anyone patched command.com to *stay* in binary mode *all* the time? >---------- >Please don't. Else how will you concatenate ASCII files that each have >a Ctrl-Z at the end? Use an explicit /A switch, that's how. It boils down to which should be the default. For most people, living in the 90's, the default should be binary. The real solution is not to use the DOS copy command with anything other than plain vanilla syntax unless you give it an explicit mode switch.
gpitcher@edpmgt.UUCP (Glenn Pitcher) (12/20/90)
In article <31600012@hpcvra.cv.hp.com.CV.HP.COM>, everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) writes: > OK, here's one for ya (and Microsoft). Lets assume that you have a program > called JUNK.COM in your current directory and it's 15385 bytes long (the > number doesn't matter). Now, do this: > COPY JUNK.* TEMPFILE Gee, I had that happen just yesterday! And I thought I was loosing it! -- Glenn Pitcher UUCP: {crash,ucsd}!edpmgt!gpitcher Programmer/Analyst & hp-sdd!teamnet!gpitcher Unix Guru in training EDP Management, Inc. * Proud member of Team.Net * =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
bcw@rti.rti.org (Bruce Wright) (12/30/90)
In article <8595@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > In article <valley.661107643@gsbsun> valley@uchicago (Doug Dougherty) writes: > >The whole "ASCII file/^Z = EOF" thing is a bug, in my view. > >All copying should be in binary mode. Editors should not append ^Zs > >to files. Foo on the Norton Editor! > > Not a bug, but a compatibility feature. MS/DOS was designed to be somewhat > compatible with CP/M so that all the CP/M applications could be easily ported. > In CP/M, files were always a multiple of 128 bytes so end of file was > indicated by filling the end of the 128 byte sector with ^Z's. > > But this was years ago. There is no excuse for editors to append ^Z's now. > In fact there is no excuse for any program not ported from CP/M (which is > just about everything) to append ^Z's. Not quite true - I think this is still arguable. There is still software out there that gets quite upset (infinite loops, or choking in various strange ways) if the ^Z padding is missing at the end of the file. There's no doubt that this software is seriously broken (the ^Z should be optional on input, certainly not required), but it's out there and in use; much of it is old and not supported by the manufacturer any more (often the manufaturer _isn't_ any more, simply because of the turnover in the PC business). Unfortunately some people still _rely_ on this software, and don't really feel they have a good alternative (conversion costs/new product costs/ etc). Even apart from software ported from CP/M, quite a bit of software for DOS 1.0 had this problem (it wasn't convenient to write a short block at the end of the file using the FCB's). Unfortunately if you are writing a commercial product you have to deal with this problem - and _anything_ you choose to do will have compatibility issues with _something_. Whoever thought up the nickname MessyDos had the right idea :-). Bruce C. Wright