🚀 go-pugleaf

john@jwt.UUCP (John Temples) writes:

> In article <jono.670739550@dec06> jono@dec06.cs.monash.edu.au (Jonathan Olive
> >	system("copy file1 file2");
> >
> >there was not enough memory to perform the copy.
> 
> The two problems with your approach are that system() has to load a
> copy of the command processor to do its job (which takes additional
> time and memory), 

   A valid complaint about system() on any OS.

> and you're assuming that there's a command called
> "copy" on the system running your program.  

   Copy is one of those commands that seems to be everywhere. If you
were trying to do a 'hyteiwk a b', you might be worried that hyteiwk is
not everywhere. Or, you could supply a copy of it with each system you
sell. Added value! 

> Since "copy" is a
> COMMAND.COM internal command, and not everyone who runs DOS uses
> COMMAND.COM, your program is non-portable.  

   Do other PC OS's really not have a command called 'copy'? Do they
REALLY not have the capability of having a simple batch file to create
that command? How poor a system!

> Also, system() usually
> fails when your switch character is not set to "/".  

   I have heard that much software fails when the switch isn't /.

> In other words,
> system() is not usually a wise choice in any "serious" program.

   I disagree. The only drawback to system() is the speed penalty of loading
another shell. There are some very good uses for system().

> You should open "file1" and "file2" and do the copy yourself, something
> like this:

   Here is the best proof that system() is the proper choice. You have
left out the hardest part of the operation -- opening the files. True,
MS-DOS and UNIX are quite happy with stream files. But when you invoke
the name of the god Portability, you invoke more than those OS's. Look
at VMS (and probably MVS and a dozen others), who have many types of
files. (In fact, VMS's stream_lf file came about only after C was
implemented on it.) If you dare open a fixed length record file with
stream attributes, you get faulty data. How do you tell the record type?
You have to stat() the file. 

   Now, to be portable, you will need to code into your open function a
test for many different file types. And hope that the next release of
the OS doesn't add a few more. Or, you can code in a simple system() of
'copy a b', and let the OS writers worry about file types and anything
else system specific. And if you don't have a 'copy' command, write a
batch file (or alias, or ...) to do it.

   Here is another good use for system(). How do you print from within a
program? I hate to tell you, but opening the device LPT1:, or PRN:, is
REALLY non-portable. Not even from OS to OS, but from one PC to another.
With the easy possibility of 5 printers attached to one PC, and a myriad
others through networks, plus all the other OS's and the odd ways they
handle printers, system() is about the only option. Either that, or you
write configuration code to handle every case you can think of, and I
can guarantee that you will miss some. And you will have trouble getting
data to the printer yourself that 'copy' will not. I have one program
that I have gone to the extent of 'biosprint()' and there is STILL a
problem with something swallowing bytes here and there that does not 
happen with 'copy'.

   So, write your data to a file. Use the system command 'printfile
filename'. Then write a batch file to implement the printfile command.
Yeah, it is slower, but it sure beats trying to maintain a mountain of
code, and it allows the USER to configure his printing as he wishes.
When you can tell a customer 'here is how to do what you want', instead
of 'not supported', you both win.