Don't try to parse Perl, only perl can parse Perl (modules like PPI come close, but still can't do everything). Use a Config:: module like choroba suggested, or if it's only one or two simple values, environment variables can sometimes be enough (see %ENV).

It is not about parsing perl. It is about replacing %%VARIABLE_NAME%% with some value in the code while installing the script...

It is not about parsing perl. It is about replacing %%VARIABLE_NAME%% with some value in the code while installing the script...

If that's really all it's about, then why not just use perl -pie 's/%%VARIABLE_NAME%%/value/g' script.pl? Or s/%%(\w+)%%/$vars{$1}/g? (These are not rhetorical questions)

A search and replace that doesn't parse Perl requires that the search pattern only appears in places where it should be replaced and nowhere else, i.e. it limits what Perl syntax can be used. If that's the case, then one can just as well use e.g. Template::Toolkit (or reinvent that wheel).

As soon as one requires the preprocessing to have even the slightest awareness of Perl syntax, then we're talking about parsing Perl. If you don't believe me, give me an example and I'll give you the counterexample that breaks it ;-)

In the situation you've described, config files or env vars are almost certainly the better solution than editing Perl source code.

Either

• use a config file like already mentioned
• require or do a dedicated file with constants only
• pass values as arguments at startup and read them from @ARGV
• set environment variables in %ENV

°) only exception is probably $VERSION in modules

• require or do a dedicated file with constants only

There are good reasons for NOT storing configuration data as Perl code:

• Re^2: conf file in Perl syntax
• Re: Accessing variables in an external hash without eval
• Re^4: The safety of string eval and block eval.
• Re^2: Storing state of execution
• Re: What's the right way to include a config file as a .pm bareword?
• Re^4: how to read conf file in perl script

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Sure. And the world is a bad place. Did you ever avoid to load a module because it can execute arbitrary code?

I would prefer command-line parameters but if the OP insists loading constants from a module isn't so bad IMHO:

package MyConf {

    use constant NOSE => q(cuke);
    use feature qw(say);
    say __PACKAGE__;
    1;
}
[download]

#!/usr/bin/env perl                                                   

use strict;
use warnings;
use feature qw(say);
use lib q(.);
use MyConf;

say qq(My nose isa @{[MyConf::NOSE]}!);

__END__
[download]

Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

As others have said, what you are trying to do can be done by config files, a simple regex or templates. There is no need to re-invent the wheel or make it square.

Another way is to control your deployment script with command line parameters: deploy.pl --script-name abc --location xyz/abc etc.

And then there are ... autotools (written in Perl I think) which can do variable substitutions to source file templates. I would not use it just for a small task. I am mentioning it because you may want to use it as your main deployment/installation framework and be able to do ./configure && make all && make container && make backup && make push-git. It requires a lot of work to get started with it. Does your use-case justify it?

Here is a skeleton just for the var-sub part (ripped from various sources on the net):

# configure.ac
AC_INIT([helloprog],[1.0],[abc@xyz.com])

AM_INIT_AUTOMAKE

MYVAR="1234abc"
AC_SUBST(MYVAR)
AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([myscript.pl])
AC_OUTPUT
[download]

# Makefile.am
bin_SCRIPTS = myscript.pl
[download]

Edit (forgot the perl script to have vars substituted):

Edit2 (the name ends in .in denoting a template input, the .pl file will be produced from that. During the configure stage, not the make.):

# myscript.pl.in
# all @MYVAR@ will be substituted by value in configure.ac file
my $var = "@MYVAR@";
print "var is : $var\n";
[download]

bootstrap it using (just once):

and then:

When IT people hear autotools, they will almost certainly parrot cmake, gradlew, maven as in a monty pythons sketch. Alas they are serious. Only a true hacker's heart fills with adrenaline when finally reached the state of ./configure && make all. But can you handle it?

bw, bliako