Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!jwt!john From: john@jwt.UUCP (John Temples) Newsgroups: comp.os.msdos.programmer Subject: Re: using "system" in C Message-ID: <1991Apr9.133728.4855@jwt.UUCP> Date: 9 Apr 91 13:37:28 GMT References: <1991Apr5.024832.2361@jwt.UUCP> Organization: Private System -- Orlando, FL Lines: 61 In article 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)