in reply to Re^2: Why do we need a \n with do FILENAME?
in thread Why do we need a \n with do FILENAME?

I do appreciate your point about undef as a legal return value, however an examination of the code sample from do shows usage expects a defined test on the return value, likely for this very reason. As I said, I suspect there is a try-catch in the file access subroutines, and so you are getting a false negative from an internal failure. You could add an extra layer of security with a -r test, guarantee an appended newline on your file name or guarantee a defined return value, but all of these are workarounds. I would be particularly hesitant to simply append the newline, as that strikes me as fragile.

Replies are listed 'Best First'.
Re^4: Why do we need a \n with do FILENAME?
by rovf (Priest) on Jul 07, 2010 at 09:23 UTC
    examination of the code sample from do shows usage expects a defined test on the return value, likely for this very reason.
    Actually the sample does not check on define, but on truth (which might have led ikegami into thinking that the file should always return true), but I believe that for this very reason this is just an example of how do might be used - otherwise the example would have explicitly say  unless (defined($return = do $file)) to make it explicit that an undef return value does not make sense. Indeed, for reading a configuration file (which is what the example is about), it makes sense to require that the config file should return true in success; but I don't think this can be taken to mean that this always should be the case.

    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
[select]
      Actually the sample does not check on define, but on truth

      For the $! case, do says

      warn "couldn't do $file: $!"    unless defined $return;

      The truth case is checking the success of the contained code, not the OS's ability to locate and execute file. I personally would go code diving before weighing in on the appropriateness of perl's behavior.

[reply]
[d/l]
[select]

      which might have led ikegami into thinking that the file should always return true

      You could require your included file to return something defined. Requiring the included file to return something true is much clearer and simpler, though, and Perl programmers are already accustomed to doing that.

[reply]
        I would agree with you if the only purpose of do would be to "load subroutines and initialization code at runtime" in a similar way as require does, but for those (rare?) cases this should be done repeatedly. However, from my understanding of do, this function is much more general: It is, in spirit, much more like eval, only that the evaluated code resides in a file, not in a string or block. This can, IMO, not only seen from the description of do, but also from the fact that $@ is set after an exception. We wouldn't place the requirment, that code evaluated by eval should return a true value unless it fails, do we? I, personally, would say that the same applies to do.

        Maybe our different views in that matters come from the fact that I'm using do in a different way. We are using it to inject (for purpose of debugging) arbitrary code at specific "hook point" in a running application.

        -- 
        Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom