mv'ing files from a C program

[RANDY S WELCH]

In article <1990Nov16.231909.20173 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) writes:

   Path: mercury.cair.du.edu!pikes!boulder!ncar!zaphod.mps.ohio-state.edu!usc!jarthur!uunet!virtech!cpcahil
   From: cpcahil at virtech.uucp (Conor P. Cahill)
   Newsgroups: comp.unix.questions
   Date: 16 Nov 90 23:19:09 GMT
   References: <22 at mixcom.UUCP> <1990Nov15.132952.11932 at virtech.uucp> <1990Nov15.183359.963 at ssd.kodak.com>
   Reply-To: cpcahil at virtech.UUCP (Conor P. Cahill)
   Distribution: na
   Organization: Virtual Technologies Inc., Sterling VA
   Lines: 27

   In article <1990Nov15.183359.963 at ssd.kodak.com> weimer at ssd.kodak.com (Gary Weimer) writes:
   >In article <1990Nov15.132952.11932 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
   >>You don't have to use system(3), you can use fork/execl(2) (or one of it's 
   >>family of functions) as follows:
   >>
   >>	if( fork() == 0 )
   >>		execl("/bin/mv","mv",oldfile,newfile,(char *)0);
   >>	else
   >>		wait((int *)0);
   >
   >That's just about exactly what system(3) does. (i.e. you gain nothing for
   >all the added code)

Isn't invoking a shell a bit much to mv a file when you can
link(2)/unlink(2)?  

-randy

-- 
Randy Welch   Mail to :  ...!ncar!scicom!bldr!randy or rwelch at du.edu
Boulder, CO   VOICE   :  303-442-6717
"Unfortunately, life contains an unavoidable element of unpredictability"
-David Lynch "The Angriest Dog in the World"