Re: system command error

Replies are listed 'Best First'.
Re^2: system command error ($_ not _) by tye (Sage) on Apr 04, 2003 at 16:16 UTC
One of my complaints about File::Find is that its silly optimization (which has caused me tons of grief over the years because it was being used in so many places where it just plain breaks) of checking the nlinks from stat (in hopes of deciding that there are no subdirectories) means that you can't assume that it has just done a stat or lstat on the file in question so you have to restat the file by name and not use the magic _ as you have done above. So you either need to prepend a $ to your first _ or you need to do something to ensure that File::Find doesn't use the silly nlinks optimization: `$File::Find::dont_use_nlink = 1;` [download] Note that if you don't disable the silly nlinks optimization, then you'll have to change that _ to $_ (or risk your script breaking in some directories on some systems) and so your script will run slower which just makes me laugh since File::Find's documentation says: If you do set `$File::Find::dont_use_nlink` to `1`, you will notice slow-downs. I particularly like the "notice" part. Yeah, sure I will. (: More than once I've tried to make the nlinks optimization something that you have to request be done for you but the emotional attachment to it for some at p5p is just too great. It looks like several improvements to the code have been made regarding this feature so it is less likely to be used when it shouldn't (other than slowing down most correct uses of File::Find). I'm not convinced that it is perfect, however, because I'm pretty sure I've run into file systems where nlinks on directories are not either always 1 or always 2+number_of_subdirectories. So now I'm mostly amused with how the emotional attachment to this has manifested itself in the module documentation. Oh well, I don't use File::Find much anymore. For trivial uses, it is usually easier to use /bin/find and for non-trivial uses it is usually easier to roll my own directory traverser than try to figure out how to use awkward call-backs to get done what I want. - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: system command error ($_ not _)
by tye (Sage) on Apr 04, 2003 at 16:16 UTC

One of my complaints about File::Find is that its silly optimization (which has caused me tons of grief over the years because it was being used in so many places where it just plain breaks) of checking the nlinks from stat (in hopes of deciding that there are no subdirectories) means that you can't assume that it has just done a stat or lstat on the file in question so you have to restat the file by name and not use the magic _ as you have done above.

So you either need to prepend a $ to your first _ or you need to do something to ensure that File::Find doesn't use the silly nlinks optimization:

    $File::Find::dont_use_nlink = 1;
[download]

File::Find

If you do set $File::Find::dont_use_nlink to 1, you will notice slow-downs.

More than once I've tried to make the nlinks optimization something that you have to request be done for you but the emotional attachment to it for some at p5p is just too great. It looks like several improvements to the code have been made regarding this feature so it is less likely to be used when it shouldn't (other than slowing down most correct uses of File::Find). I'm not convinced that it is perfect, however, because I'm pretty sure I've run into file systems where nlinks on directories are not either always 1 or always 2+number_of_subdirectories. So now I'm mostly amused with how the emotional attachment to this has manifested itself in the module documentation.

Oh well, I don't use File::Find much anymore. For trivial uses, it is usually easier to use /bin/find and for non-trivial uses it is usually easier to roll my own directory traverser than try to figure out how to use awkward call-backs to get done what I want.

tye

[reply]
[d/l]
[select]