in reply to Translating Module Names to File Names

Well, if I have a "use mymodule.pm;" in my code, how does perl work out when the physical file is to actually include the module code? The @INC array contains the list of places that perl looks in. So I thing your approach of going through this array is sound.

Since @INC can be modified at run time, this will guarantee that you are looking at exactly what perl itself will look at at the time you call the function. This is probably the safest (read: most reliable) way to get the file name.

  • Comment on Re: Translating Module Names to File Names

Replies are listed 'Best First'.
(bbfu) (@INC can be modified at run time) Re: Re: Translating Module Names to File Names
by bbfu (Curate) on Feb 21, 2001 at 04:52 UTC

    Ah, yes. @INC can be modified at run time. And a `perldoc -l $module` wouldn't pick that up, now would it? So there ya go, chipmunk, Maclir agrees with me. ;-)

    Anyway, thanks for your perspective, Maclir (and chipmunk too!). I was suddenly afraid I was doing something stupid. =)

    bbfu
    Seasons don't fear The Reaper.
    Nor do the wind, the sun, and the rain.
    We can be like they are.

[reply]
[d/l]
      Well, I would not go so far as saying "And a `perldoc -l $module` wouldn't pick that up, now would it?". I guess it all depends on how that process is spawned - I would have thought it ran in the same shell environment (but what do I know?)

      Maybe someone should test it and see?

[reply]

        I'm pretty sure the @INC array isn't included in the shell environment. If it is, of course, it would probably pick it up. But I'm pretty sure that @INC (especially changes made within a script) are not propagated down to spawned child processes.

        Of course, as always, I could be wrong. =)

        bbfu
        Seasons don't fear The Reaper.
        Nor do the wind, the sun, and the rain.
        We can be like they are.

[reply]

In Section Cool Uses for Perl