🚀 go-pugleaf

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