Thread: Equivalent of Dos 'copy' in C ?

Hi all,

I've got another question. Is there a function in C for copy?
I saw this somewhere and wondering if there's one for 'copy':

remove("Filename.txt"); // equivalent to 'delete filename.txt in dos
rename("Fileold.txt", "Filenew.txt"); // equivalent to 'rename fileold.txt filenew.txt

what about .. copy file1.txt file2.txt .. is there one for C?

I tried copy, copyfile, filecopy all not working.

Thanks,
YetBo

Hi Dino thanks for the quick reply.

Mind showing me how the system() function works.

And Happy Birthday !!!

The string passed to system is executed as though it was entered at the command line. This makes it nice & easy for some things - but whatever you put in there is OS-dependant, and not really part of C, per se. Sometimes it's viewed as bad style.

That being said, copy still works in Windows, on *nix you'd use the 'cp' command.

Originally Posted by brewbuck

Actually, switching out to the system copy command with system() is probably the most painless method.

Copying a file is more than just creating a file with the same contents as some other file. You also need to preserve the creation date, file permissions, ownership, and any other attributes. Settings these attributes is a very non-portable operation, and in fact, it is impossible to implement a true file copy in C using only standard functions.

So if you're going to delve into non-portability (and you must, if you need to copy files), you may as well reduce the pain to the minimum level possible by just calling system().

Well, I think it can be done in a portable way through glib.

Originally Posted by brewbuck

What exactly do you think glib does internally? It calls platform-specific functions. There's nothing wrong with that, but it's incorrect to say that linking to some library which hides the non-portable details somehow makes your code portable.

Your code still won't compile on any platform which isn't supported by glib. That's non-portable by definition.

Non-portability is not a bad thing. The portable core of C and C++ is extremely restricted in what it can do. Real programs HAVE to go outside of those bounds.

No, your definition of portability is wrong. By your definition, not even the c standard library would be considered portable.

No, your definition of portability is wrong.

What exactly is your definition of portability, then? Because what he said falls in line with every other statement I've heard about portability? The C standard library is a uniform interface that is standardized across all interfaces - but the code to implement is extremely platform dependant. Working with files, etc...

brewbuck - good point, I agree - I was sharing that more as an intro to the "system" function in general though. I think it's grossly overused by people who have recently discovered it.

Originally Posted by sean

What exactly is your definition of portability, then? Because what he said falls in line with every other statement I've heard about portability? The C standard library is a uniform interface that is standardized across all interfaces - but the code to implement is extremely platform dependant. Working with files, etc...

brewbuck - good point, I agree - I was sharing that more as an intro to the "system" function in general though. I think it's grossly overused by people who have recently discovered it.

I can simply use what he said about glib with the c standard library and prove that he's wrong:

What exactly do you think "the c standard library" does internally? It calls platform-specific functions.

Originally Posted by brewbuck

The C library is a STANDARD which all compilers must provide in order to claim standards compliance. The features granted by the standard are required, and you can depend on them.

glib is not a standard, is not required to be present on a system, is not required to be operable on any possible system.

That's completely unrelated to the concept of portability. Being standard and being portable are 2 completely different concept.

Originally Posted by brewbuck

If your code adheres to all standard C rules, then your code is portable to any environment with a standard C compiler. If you're claiming otherwise, I'd like to hear your argument.

Again, this is completely irrelevant to the previous discussion and I never said that. It just seems to me that you're unable to admit that you were wrong.