🚀 go-pugleaf

In article <1992Nov16.232453.17042@spang.Camosun.BC.CA> dbarker@spang.Camosun.BC.CA (Deryk Barker) writes:
...
>Try using the /b(inary) qualifier to the copy command. Trying to do
>the same thing to a HP IIP I got a similar result. Using /b cured it
>(and, I think, removed the necessity for a manual press of the
>FormFeed button); strangely enough I have *never* have to use /b when
>copying executable from disk to disk.
...

The DOS "COPY" command has a built-in set of rules about whether to
use ASCII or BINARY mode as a default.  It uses BINARY mode whenever a
simple image copy is known to be safe.  Otherwise, it assumes ASCII
mode.  Thus:

    1.	Copying a single file to another single file is done in binary;
	whatever the old image represented, the copy wil be just the
	same.

    2.	A many-to-many copy (using wildcards) is also done in binary,
	since it is just multiple instances of case 1.

    3.	Concatenating multiple files onto a single target defaults to
	ASCII, since there may be terminating CTRL-Z characters that
	need to be stripped out in order to make a valid ASCII target.

    4.	Copying to a target device "known" to be ASCII is, of course,
	performed in ASCII mode.  (... and we all know that printers,
	COM ports, and the like are ASCII devices, right?  Well, "COPY"
	is pretty certain that they are, anyway.)

Binary and ASCII modes are a relic of the CP/M filesystem, with which
DOS still maintains a degree of compatibility (and you thought that
8088 compatibility was the only boat anchor that DOS was still dragging
along!).

Bob Nichols
AT&T Bell Laboratories
rnichols@ihlpm.ih.att.com