in reply to Re^2: removing files with perl based on age and name
in thread removing files with perl based on age and name

This node falls below the community's minimum standard of quality and will not be displayed.
  • Comment on Re^3: removing files with perl based on age and name

Replies are listed 'Best First'.
Re^4: removing files with perl based on age and name
by roboticus (Chancellor) on Jul 18, 2014 at 17:17 UTC

    gurpreetsingh13:

    They think everything should be in perl itself and think that pure perl can take them to the other side.

    Untrue--there are numerous articles where people suggested just using a command line operation instead of writing a perl script. I've done so a few times myself.

    We have a unix system and should recognize the power of that OS which has been there since 30 years ago. What is the problem there in shipping out something to shell when the work gets done easily.

    Many of us here are Unix-centric and have no problem shelling out for some tasks. But the way I read the situation is more like this:

    Hippo: Why are you using the cutting blade of your swiss-army knife to remove that screw? You know it has a couple screwdriver blades, right?
    gurpreetsingh13: That's the problem I have with you guys...knife blades are perfectly capable of opening paint cans, removing screws, driving nails. You don't need all those other fancy attachments.

    Hmmm ... okay. Or maybe a better analogy might be this:

    Hippo: You're trying to drive a nail with a chainsaw. Are you sure you really need the chainsaw to be running while you're doing that? Seems a bit iffy.
    gurpreetsingh13: But chainsaws are powerful tools! Why not use them?

    But ... the blood ... the detached limbs ... possible severed heads ...

    But since this code is workable (tested few times on my home directory), so I had to put that rm -rf there.

    Just because you tested it in your home directory, doesn't make it require -rf. But I'm guessing you didn't test it in your home directory, unless you (a) just created a brand-new virtual machine to run it under, (b) just created a new account to run it under, (c) had spaces in the names of all your important files and directory names, or (d) didn't have any important files anyway.

    This is a simple script and we can forget about execution speed here.Any intelligent guy would never run the script without reading the code.

    True, instead he'd delete the script and then run away screaming. That's a pretty scary script to have on your system. If you happened to be in the wrong directory and ran it, your first clue to a problem might be something like:

    bash: stat: command not found

    showing up after a couple minutes of disk thrashing. Since it helpfully provides -r, it could merrily wreak havok on the filesystem ... at least until enough programs died that the script would fail.

    While I agree that shelling out to other programs to solve a problem is fine, it pains me to see:

    • That you'd prefer to ignore a basic, well-known/understood capability of the tool. You can do looping in bash and run perl scripts multiple times to process multiple files...but I wouldn't recommend it as an alternative to a for loop.
    • That you'd actually put such a dangerous script in a thread where a novice is trying to perform a task. If Jocqui decided to run a variation of that script, serious trouble could ensue.

    hippo raised a couple issues with the script, but your dismissal of those issues is rather peremptory.

    Update: A couple fixes: s/amputations/limbs/, changed a ? to a !.

    ...roboticus

    When your only tool is a hammer, all problems look like your thumb.

[reply]
[d/l]
      Thank you for your detailed answer, roboticus, I fully endorse it. There were numerous things in gurpreetsingh13's post that I would have wanted to comment (not necessarily exactly the sames as you, but mostly along the same lines), but you did it in a masterful way, no point to add further debunking, you just did it right.

      Just in case someone might understand it false, I am using almost daily Unix powerful tools (sort, find, cut, etc., sometimes even awk and sed, and many others), and yes, they are very powerful. For example, one thing I am doing regularly is to use the Unix sort utility to sort (usually with relatively complicated sort, field by field, for which the Unix sort is very good) a very large file and then piping the output to a Perl program that will remove duplicates or do all kinds of other interesting things. In some cases, I am also using the Unix shell to create parallel Perl processes in a very easy way. But shelling out of Perl to just stat a file last modification date, to remove a file or changing permissions is just plain stupid non-sense when the language can do it so easily.

      To gurpreetsingh13: I did not downvote your original post with the script, because, despite what I said earlier about its shortcomings, I still think it can be considered as a valuable and useful contribution (even though I fully agree with Hippo's comments on it), but, yes, I did downvote your last answer, which is just pathetically wrong, as beautifully demonstrated by roboticus. Having done that, I can see that I am far from being the only one: you've made it to the top worst node of the day (and probably soon top worst node of the week, it is probably just a matter of time for update).

      No personal hostility, I think your argument is just plain wrong.

[reply]
[d/l]

      This is without a doubt the best response I've ever read on this site.

[reply]
Re^4: removing files with perl based on age and name
by graff (Chancellor) on Jul 18, 2014 at 23:20 UTC
    The "stat" function is implemented in Perl as a direct system call OS library call because it is commonly recognized that starting up and shutting down a whole shell process just to stat a file will tend to be a noticeable waste of run time, especially given the very typical usage (like in the code above) that could end up doing this relatively costly business many many times. (update: likewise for unlink, rename, and similar built-ins)

    Plus, /usr/bin/stat tends to be one of those "core utilities" that don't actually have equivalent command-line syntax from one unix/linux OS to the next. (update: it might be /usr/local/bin/stat, or as pointed out above, it might not be found at all on some systems)

    To clarify the run-time issue... Just for grins I found a directory on my mac laptop (2.2GHz intel core i7, osx 10.8.5, perl 5.12) that happens to contain 12.6K files, and I tried two different scripts: 

    $ cat /tmp/j1.pl
#!/usr/bin/perl
use strict;
use warnings;
while (<>) {
    chomp;
    my $stat = `stat $_`;
}

$ cat /tmp/j2.pl
#!/usr/bin/perl
use strict;
use warnings;
while (<>) {
    chomp;
    my $stat = stat $_;
}

$ cd path/with/12.6K_files/

$ ls | time /tmp/j1.pl
       60.05 real        12.76 user        31.45 sys

$ ls | time /tmp/j2.pl
        0.07 real         0.01 user         0.02 sys

    [download]
    I did it a few times, in both orders (j1 right after j2 and vice-versa), and the results were consistent. Imagine what the difference would be over a whole disk with, say, a million files.

    As for the cross-platform portability issue… I have to ask: which OS / version of stat are you using? The version of /usr/bin/stat I have on my mac doesn't support the particular command-line syntax you used, so even if I wanted to run your script, I couldn't.

    UPDATE: Oh, I forgot to mention… Have you tried running your script in a directory where file names contain spaces, and/or parens, and/or apostrophes, and/or ampersands, and/or … (I hope you get the idea).

[reply]
[d/l]

In Section Seekers of Perl Wisdom