in reply to My first thought was to build a macro... was I right?

What is "rmtree"?

I can hazard a guess as to what it does, but is it a OS command, a function from a module?

Also, why are you evaling built-ins?

In my (breif) tests, nothing ever gets put into $@ whether or not the function succeeded or failed. Any error is always available in $! and never $@.

I'm not at all sure of the utility of putting built-ins into your own subs? What's wrong with

unlink $file or $o->LOG( 'error', "$file: $!"); rmdir $tree or $o->LOG( 'error', "$tree: $!");

Update:Do all the other responders know something I don't? They all go along with testing and printing $@???


Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

Replies are listed 'Best First'.
Re: Re: My first thought was to build a macro... was I right?
by princepawn (Parson) on Dec 03, 2002 at 16:02 UTC
    What is "rmtree"? I can hazard a guess as to what it does, but is it a OS command, a function from a module?
    rmtree is a sub in File::Path

    Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

      Okay, that makes sense. However, I just tried to create errors by deleting a) a non-existant subdir. b) a subdir which I did not have permission to delete. I tried this using eval as shown in your post and again in neither case did anything end up in $@. I did get various messages to STDERR:

      Can't make directory testtesttest read+writeable: Permission denied at + C:\test\QOTW\test.pl line 27 Can't read testtesttest: Invalid argument at C:\test\QOTW\test.pl line + 27 Can't make directory testtesttest writeable: Permission denied at C:\t +est\QOTW\test.pl line 27 Can't remove directory testtesttest: Permission denied at C:\test\QOTW +\test.pl line 27 and can't restore permissions to 0777 Should be no errors $!: 'Permission denied' $@: '' Can't make directory testtesttest read+writeable: Permission denied at + C:\test\QOTW\test.pl line 31 Can't read testtesttest: Invalid argument at C:\test\QOTW\test.pl line + 31 Can't make directory testtesttest writeable: Permission denied at C:\t +est\QOTW\test.pl line 31 Can't remove directory testtesttest: Permission denied at C:\test\QOTW +\test.pl line 31 and can't restore permissions to 0777 Should be errors $!: 'Permission denied' $@: ''

      Looking at the docs I saw this:

      Note also that the occurrence of errors in rmtree can be determined only by trapping diagnostic messages using $SIG{__WARN__}; it is not apparent from the return value.

      Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
      Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
      Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
      Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

Re: Re: My first thought was to build a macro... was I right?
by miki (Initiate) on Dec 04, 2002 at 14:38 UTC
    from Programming Perl:
    $@
    The currently raised exception or the Perl syntax error message from the last eval operation. (Mnemonic: where was the syntax error "at"?) Unlike $! ($OS_ERROR), which is set on failure but not cleared on success, $@ is guaranteed to be set (to a true value) if the last eval had a compilation error or run-time exception, and guaranteed to be cleared (to a false value) if no such problem occurred. (...)

    HTH

      That's all very well, but if the file/dir string passed to unlink/rmtree simply doesn't exist or script does not have sufficient rights to perform the deletion, the will be neither a compilation error nor a run-time exception raised. I know cos I tried both situations. Therefore $@ will never be set, so neither failure will be detected.

      $! is set in both cases.

      I therefore can see no benefit in evaling these calls to functions. Better to use the standard idiom of unlink $file or die/warn/LOG $!; and rmtree $dir or die/warn/LOG $!; don't you think?


      Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
      Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
      Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
      Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

        Maybe a use Fatal somewhere? Otherwise $@ doesn't make a lot of sense...

        (I used to like Fatal, being an exception throwing sort of person. However it ended up causing me more problems than it solved - producing exactly this sort of confusion :-)