Path: utzoo!attcan!lsuc!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: TC "system" and "setcolor" questions answered Message-ID: <2622AC6D.28527@maccs.dcss.mcmaster.ca> Date: 11 Apr 90 04:02:52 GMT References: <1990Mar31.153231.4926@druid.uucp> <2718@unocss.unomaha.edu> Distribution: na Organization: McMaster University, Hamilton, Ontario Lines: 32 In article <2718@unocss.unomaha.edu> ho@fergvax.unl.edu writes: $Would something akin to $execl ("c:/command.com", "command", "/c", "dir", NULL) $work? This should pull up command.com. The /c parameter makes command $interpret its arguments as actual commands to execute, and return control $when it's done. It will work some of the time, but it's an extrememly bad programming practice to hard-code the path and filename of the command processor, especially when the correct version of this information is passed to your program at run-time. The above will not work - for machines booted from disks other than C (e.g. floppy boots, some networks) - for networks that boot from a remote drive C and then unlink that drive (we have such a network here at McMaster) - for machines booted from directories other than the root directory - for machines using a COMMAND.COM substitute such as 4DOS, although one might want to use COMMAND.COM specifically for this if you're not sure that the replacement has the command you want - if you try to port your program to another OS If you want to run internal commands, why not just use system ()? If you don't want to, then you should at least use the COMSPEC environment variable to determine the path for the command processor. You can access environment variables with the getenv () function. -- More half-baked ideas from the oven of: **************************************************************************** Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca = "\nI'm only an undergraduate ... for now!\n";