Re^3: removing directories with wildcard glob in OS-portable way

Trust me, the OS detection is happening, just not in your code. But that's not the problem.

It's all teh other stuff that is happening under the covers that you also don't know about.

This:

perl -E"system q[for /d %d in (scale-*) do @rd /q /s %d]"
[download]

Does the same job as this:

perl -MFile::Path -MFile::Spec -wE"File::Path::remove_tree(glob(File::
+Spec->catdir('.','scale-').'*'));"
[download]

But uses only 7% of the user cpu and 3% of the system cpu.

Does it matter? Depends alot on how big the trees are and how often you run the command I guess, but why use cycles you don't have to.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^3: removing directories with wildcard glob in OS-portable way Select or Download Code

Replies are listed 'Best First'.
Re^4: removing directories with wildcard glob in OS-portable way by Anonymous Monk on Dec 30, 2012 at 03:53 UTC
Pretty shallow trees (1 level, a few subdirs, a few thousand files total) and the operation only happens once per run (a run may persist for hours to weeks or possibly months), so this does not need to be optimized at all. I was more concerned about heading off any "why doesn't your code work on my non-*nix OS?" Will trade processor cycles for programming cycles here, I think, and avoid having to know about all those DOS /flags, and similarly for any other OS somebody tries to use. But that sort of thing--dropping to the system level for intensive file management--is good to know if I need increased performance for similar tasks in the future.	[reply]

Replies are listed 'Best First'.

Re^4: removing directories with wildcard glob in OS-portable way
by Anonymous Monk on Dec 30, 2012 at 03:53 UTC

But that sort of thing--dropping to the system level for intensive file management--is good to know if I need increased performance for similar tasks in the future.

[reply]