jfbeaulieu
asked on
remove in UNIX and ANSI C
Hi,
I have to make a CGI in C for a UNIX station but we don't have UNIX at the office and I never used UNIX in the past (or let say 3 weeks.. 10 years ago). I would like to compile an ANSI C file with visual C++ and ship the source code to the webmaster in Toronto , but I don't know if there's an equivalent for the remove(filename) function in either ANSI C or either in the UNIX toolkit (and if so, What is the include file?)
Also, is there something available on the web, a free compiler or either a table with functions that can allow me to check if each function is really ANSI C?
I have to make a CGI in C for a UNIX station but we don't have UNIX at the office and I never used UNIX in the past (or let say 3 weeks.. 10 years ago). I would like to compile an ANSI C file with visual C++ and ship the source code to the webmaster in Toronto , but I don't know if there's an equivalent for the remove(filename) function in either ANSI C or either in the UNIX toolkit (and if so, What is the include file?)
Also, is there something available on the web, a free compiler or either a table with functions that can allow me to check if each function is really ANSI C?
ozo
Both ANSI and POSIX specify a remove(const char *filename) function
I don't know where there's a list of ANSI functions, but here's a list of POSIX functions:
http://www.ora.com/catalog/posix/toc.html
For a free compiler, or a free Unix, you might try:
http://www.fsf.org/
http://www.ora.com/catalog/posix/toc.html
For a free compiler, or a free Unix, you might try:
http://www.fsf.org/
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
On what system does it not work?
I thought remove was quivalent to unlink on a file, and equivalent to rmdir on a directory.
I thought remove was quivalent to unlink on a file, and equivalent to rmdir on a directory.
Although remove failed on AT&T System V R. 3.1 and on Borland C++ 4.0 that is not the issue here.
It seems that I failed to explain the issue correctly.
If you call remove() on a file name in any directory, and said file happens to be a link to another file, it will not be removed. If you call unlink() it will remove that file.
On the other hand, if a given file in a directory is the source file for a series of links, calling remove() on this file will only remove the source file, leaving all the links intact but pointing to nowhere!
The behavior for unlink() and remove() is as follows:
Calling unlink() on a file name that is a link to a source file will remove the link file name from the file system.
Calling unlink() on a file name that is a physical file to which other files may (or may not ) be linked to, will remove the physical file and all links to that file.
Calling remove() on a file name that is a link to another file will fail and will not remove the link from the file system.
Calling remove on a physical file that has linked files to it will remove the physical file, but not the links, creating potential problems for other applications.
In general it is recomended that you use unlink(), rather than remove() unless you take into account the behaviour described above and take appropiate action to control the possible side effects.
unlink therfore, is not equivalent to remove, its only similar.
Using a Win95/NT analogy (which doesn't work on 95/NT :-)), links are the equivalent of shortcuts, calling remove() to delete a shortcut is not allowed in UNIX. Calling unlink() to remove the original file, deletes the original file and all shortcuts to it. Etc.
Hope this clarifies the issue.
It seems that I failed to explain the issue correctly.
If you call remove() on a file name in any directory, and said file happens to be a link to another file, it will not be removed. If you call unlink() it will remove that file.
On the other hand, if a given file in a directory is the source file for a series of links, calling remove() on this file will only remove the source file, leaving all the links intact but pointing to nowhere!
The behavior for unlink() and remove() is as follows:
Calling unlink() on a file name that is a link to a source file will remove the link file name from the file system.
Calling unlink() on a file name that is a physical file to which other files may (or may not ) be linked to, will remove the physical file and all links to that file.
Calling remove() on a file name that is a link to another file will fail and will not remove the link from the file system.
Calling remove on a physical file that has linked files to it will remove the physical file, but not the links, creating potential problems for other applications.
In general it is recomended that you use unlink(), rather than remove() unless you take into account the behaviour described above and take appropiate action to control the possible side effects.
unlink therfore, is not equivalent to remove, its only similar.
Using a Win95/NT analogy (which doesn't work on 95/NT :-)), links are the equivalent of shortcuts, calling remove() to delete a shortcut is not allowed in UNIX. Calling unlink() to remove the original file, deletes the original file and all shortcuts to it. Etc.
Hope this clarifies the issue.
I suppose the issue then is which behavior is equivalent to the 'remove(filename)'
function that jfbeaulieu wanted.
But my understanding was that the standard POSIX unlink() on a multiply linked file
would remove the named link, leaving all other links intact.
(unless you're talking about symbolic links, rather than hard links)
This is identical to the behavior of remove().
It sounds like your AT&T System V R. 3.1 is neither POSIX nor ANSI conforming.
If jfbeaulieu needs information on a non-conforming system,
we will need to know what system that is before we can answer.
Oh, and I forgot to say what the include files were. For remove:
#include <stdio.h>
int remove(const char *path);
and for unlink:
#include <unistd.h>
int unlink(const char *path);
At least by ANSI or POSIX standards.
I would think remove should be more portable, since unlink() is
not part of the ANSI C standard
function that jfbeaulieu wanted.
But my understanding was that the standard POSIX unlink() on a multiply linked file
would remove the named link, leaving all other links intact.
(unless you're talking about symbolic links, rather than hard links)
This is identical to the behavior of remove().
It sounds like your AT&T System V R. 3.1 is neither POSIX nor ANSI conforming.
If jfbeaulieu needs information on a non-conforming system,
we will need to know what system that is before we can answer.
Oh, and I forgot to say what the include files were. For remove:
#include <stdio.h>
int remove(const char *path);
and for unlink:
#include <unistd.h>
int unlink(const char *path);
At least by ANSI or POSIX standards.
I would think remove should be more portable, since unlink() is
not part of the ANSI C standard