🚀 go-pugleaf

In article <Nuq3Z1w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
>   Copy is one of those commands that seems to be everywhere.
>   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!

You don't even have to go to another OS to lose "copy" -- just install
the MKS toolkit, or any other package which replaces COMMAND.COM with
something usable.

Have you ever seen a professional program which, in its installation
instructions, says "now, if your system does not have a 'copy' command,
you must create a batch file that copies a file from the first argument
to the second."  I certainly haven't.  And what if you have a 'copy'
command, but the arguments to it are not interpreted as 'copy from to'?

>> Also, system() usually
>> fails when your switch character is not set to "/".  
>
>   I have heard that much software fails when the switch isn't /.

I wouldn't go so far as to say "much", but why use a system call which
has a known common failure mode?  (under DOS, anyway.)

>The only drawback to system() is the speed penalty of loading
>another shell.

What about the memory cost of the extra shell?  Certainly a concern
under DOS, and the reason this thread was started!

>   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.

If you're going to write a program that does file I/O and try to run it
on different platforms which have different file system semantics,
you're not going to be able to avoid OS-specific code.  Ok, so you've
copied a file with the system() call.  Now how do you *read* a file
into your program?

> Here is another good use for system(). How do you print from within a
>program? [...] system() is about the only option.  So, write your data
>to a file. Use the system command 'printfile filename'. Then write a
>batch file to implement the printfile command.

Yea, but the "printfile" command already exists on my system and sends
the file to the line printer.  I guess I can't use your program to
print files to the laser printer, huh?  And again, have you ever seen a
professional program that required you to set up a batch file to print
programs?  Or for that matter, a program that required a user to even
know what a batch file is?

The correct way to do it, if you want to configure for different
printing environments, is to ask the user what command will print a
file to the desired printer.  Then exec() or spawn() this program,
handing it the print file on its standard input, if possible.  Of
course, under a single-tasking environment like DOS, you may end up
having to talk directly to the hardware.
-- 
John W. Temples -- john@jwt.UUCP (uunet!jwt!john)