3 ms·
Wait. What? 1) Is he implying that launching a perl interpreter is somehow a more lightweight operation than launching ls and having it stat() half a dozen fil
by yan 17y ago
Wait. What?
1) Is he implying that launching a perl interpreter is somehow a more lightweight operation than launching ls and having it stat() half a dozen files? Having ls check if a file exists 99% of the time won't even touch the disk. If you're working in that directory, those inodes will probably be cached. Running stat() on a cached inode is hardly more expensive than a system call. Read: cheap. Now perl launching will probably load a few libs and check a few files before even getting to his one-liner.
2) Am I the only one, who in my ~10 years of running unix-like operating systems have never created a filename with a newline char in it? Like even when opening obscure filesystems, never.
3) Does he think unlink() skips the check for the file's existence?
4) If he wanted to overcomplicate things and make sure everything's kosher, why not:
find . -maxdepth 1 -type f -name '*.c' -delete
Whenever I see anything piped to a perl one liner, 4 times out of 5 it's some sort of hack that can be done with standard utils.
It also grinds my gears when people take longer to think of making something more efficient than the amount of CPU time they'll save in their lives of using that 'more efficient' solution. So he spent a minute coming up with this and ten minutes posting about it. Now, will he save roughly 11 minutes of execution time in his life while running this "superior" command (also count that it takes longer to type)? If not, he wasted his time.
From his sig: "Smalltalk/Perl/Unix consulting". When you have a large-enough hammer....
- geocar 17y ago1) 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
- basugasubaku 17y agoThis is not the point of what he is saying. Read the context of the thread. It is a reply to this: http://groups.google.com/group/comp.unix.shell/msg/30e16d21dcce4c3f http://groups.google.com/group/comp.unix.shell/msg/30e16d21d... Randal is pointing out that piping the output of ls to the perl interpreter is dangerous and shows the safer way to do what the original poster wanted.
- tptacek 17y agoYou aren't going to create a file with a newline in the name. The person who wants to totally screw you over is going to create the file with the newline in the name.
- yan 17y agoI realize that. The example he used was a collection of c files, leading me to believe he was showing a personal collection of source as an example, wrongly or rightly. And I realize you aren't going to be creating files with newlines in them (or leading dashes, or many dots, etc), but once you get into a territory of someone being able to do that, and you're not competing in a CTF, I'd say there are larger issues to deal with.
- basugasubaku 17y agoI can do no better than quote Randal himself again, from the same thread: "Well, there was a very embarassing error for Apple a few years ago for the 10.3 to 10.4 upgrade as I recall. Apparently, if you had a space in your home disk name, all sorts of files got deleted. So, the moral is, no matter how rare you think something is, that's NO EXCUSE for not doing the right thing for all possible characters." http://groups.google.com/group/comp.unix.shell/msg/504a75cc7d87e16c http://groups.google.com/group/comp.unix.shell/msg/504a75cc7... http://groups.google.com/group/comp.unix.shell/msg/0385fc2d1dbf745d http://groups.google.com/group/comp.unix.shell/msg/0385fc2d1...
- nailer 17y agoSpaces in names are not rare - space is part of natural language, a filename or volume name in considered to be a single line label.