Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: use of already eval()ed module (from string)

by LanX (Saint)
on Jan 08, 2019 at 21:17 UTC ( [id://1228232]=note: print w/replies, xml ) Need Help??


in reply to use of already eval()ed module (from string)

The cleanest solution is to tell Perl not to retrieve the source from the file system but from the string.

require describes various possibilities how to add a hook to @INC, which provides the needed source.( search for You can also insert hooks into the import facility )

Maybe you might just want to have a look into this demo of mine:

[WEBPERL] dynamically importing non-bundled modules via http

and adjust it to your needs.

HTH! :)

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

  • Comment on Re: use of already eval()ed module (from string)

Replies are listed 'Best First'.
Re^2: use of already eval()ed module (from string)
by bliako (Monsignor) on Jan 08, 2019 at 22:17 UTC

    thanks for the pointers. yes the code is in strings and not on file. so I do not have to use the hook yet

      I'm afraid you are missing the point here.

      But as long as you're happy, it's OK for me. :)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        LanX, I think I got the point but please correct me if not:

        • install the hook in @INC to read any required module via a network transfer or even from an array of strings each representing a module.
        • do not eval any module at all. Instead eval the executable/test script. For each of its required modules, if not found in @INC will eventually reach the hook sub and get it to load.
        • in this way only required modules are eval'ed, the rest wait either in the array of strings (as is the case with me) or at the server if via network.

        All this is nice but I omitted one detail: The module files read are encrypted. The user supplies a password at runtime in order to be able to load them. So, with this detail, the trilemma is:

        • use the password to decrypt all the modules at once, destroy the password-var, keep the modules in-memory-waiting for the hook to load them whenever needed. Modules stay in the array of strings as plaintext, for the sake of destroying the password-var and also not statically bundling the app with lots of modules.
        • store the password in the hook to decrypt module-strings whenever requested. This is the dynamic bundling so-to-speak but with the danger that the password remains in memory for the time of the execution.
        • do not use a hook, but decrypt the modules at once, destroy the password, eval ALL the modules (static bundling) before executing the test script, destroy all plaintext module strings - essentially within a a few (critical) seconds.

        The last option minimises the danger of memory-dumping the password and the plaintext module strings but does eval all the modules at once (they may not be needed) and then executes the script. The up-side is that modules now reside in the perl interpreter and memory-dumping that will take significantly more effort than memory-dumping a plaintext string variable.

        So, I am good+genki with 3rd option (Update: I believe...),

        thanks, bliako

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1228232]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (2)
As of 2024-04-20 06:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found