3 ms·
1) stat() is a system call, so one system call is bound to be faster than two. 2) Sneaky users do this; they create files like /dev/shm/...\n-rf\n.. and you'd b
by geocar 17y ago
1) stat() is a system call, so one system call is bound to be faster than two.
2) Sneaky users do this; they create files like /dev/shm/...\n-rf\n.. and you'd better know how to delete it correctly.
3) ???
4) -delete is a GNU extension.
- yan 17y ago1) Just the system call overhead is not much compared to what the system call actually does, so it depends on what you're calling. Two system calls versus one with identically-cached information, sure it's slower. I'm just saying perl will also probably stat() and if not perl, the unlink() system call would perform the same function. When you're modifying files and flushing it to a drive, especially while using the shell interactively, the sys call overhead is completely negligible. All I'm trying to say is claiming the first command as inefficient is groundless; you execute it as a human and once -- it won't feel any slower. 2) If cleaning up after malicious users, sure why not. Doing this in your source tree or during normal usage? I don't know. 3) He mentioned ls stat()ing files as an inefficiency since the shell does it and ls does as well. 4) FIND(1) BSD General Commands Manual FIND(1) NAME find -- walk a file hierarchy ... -delete Delete found files and/or directories. Always returns true. This executes from the current working directory as find recurses