Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!fernwood!uupsi!fozzie!stanley From: stanley@phoenix.com (John Stanley) Newsgroups: comp.os.msdos.programmer Subject: Re: using "system" in C Message-ID: Date: 8 Apr 91 07:33:34 GMT References: <1991Apr5.024832.2361@jwt.UUCP> Organization: Mad Scientist Lines: 79 john@jwt.UUCP (John Temples) writes: > In article 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.