Try this approach: (updated) First, add the following lines to one of your scripts, starting at approximately the second line of the script, to test my method:

no warnings 'layers';
use open ':locale';
use warnings 'all';
[download]

If that works, then test the following Perl one-liner on another one of your scripts. It will modifiy the script itself.

perl -pi.bak -e "if( $. == 2 ) { $_ = q/no warnings 'layer';\n use ope
+n ':locale';\nuse warnings 'all';\n$_/;}" myscript.pl
[download]

...where, after testing to make sure it didn't completely wreck "myscript.pl", you go ahead and run that on all the scripts you need modified. The effect will be to add the following line to the 2nd line of each script on which you run the command:

no warnings 'layer'; # This squelches any warning due
             # to the open pragma not being able to find
             # a locale definition in your environment
             # variables.
use open ':locale'; # set a default locale for all IO
                    # in your script based on env vars.
use warnings 'all';
[download]

Please read documentation on the open pragma to understand what is at work here. And PLEASE test this on just one script first; I haven't tested it.

I'm not sure if I understand. If you have to open your files with different layers depending on an environment variable, then something like this should do the trick:

open my $in, "<:$ENV{LAYER}", $infile or die $!;
open my $out, ">:$ENV{LAYER}", $outfile or die $!;
# ...
[download]

Of course if you depend like that one an environment variable then you should take care of doing some validation: the above is meant as a minimal example...

PS: it's clear that English is not your mother tongue, it's not mine either: so I suggest you take a deep breath and try to find a good wording to express your questions, because I bet I'm not the only one having difficulties to understand what you mean.

From my understanding of the problem, he's trying to make changes to a pre-existing script, without wanting to look through and modify the script line by line.

Depending on the scope of what's being changed, I could see uses for this. (you could also use it for adding some logging to the open function, without having to explicitly do it each time ... useful when debugging).

For those of us paranoid folks, we might not call the internal open directly, and have a function/method/whatever that gets called, and does whatever error checking / locking / logging / etc, that gets done universally

(and although I'm not going to claim to know exactly what singam was asking, during my undergrad, I did tech support at a university w/ a fairly large number of non-native english speakers)

I have a number of perl scripts which inturn contains a number of open functions.now... It is time consuming to change in each and every file.

This is approximately the reasoning I guessed you were using. It's flawed reasoning, because it contains a false economy.

For each script that you have, it will take you about 45 seconds to add an include or use line at the beginning (to pull in your custom function), run a search and replace (to turn open into mypackage::open or somesuch), and save, then you have to test each script, but probably everything will just work.

If you do it the other way, it will take you 30 seconds to add the include or use line at the beginning that causes open to be redefined, and save, then you have to test each script. So you save fifteen seconds per script. However, there will probably be unforseen problems with some of the scripts that will cause weird bugs and result time spent debugging, which will more than eat up your saved seconds. What is worse, next month or next year when you try to add a feature to one of your scripts, and you descover that your changes don't quite do what you thought they should, you'll at first think your changes are wrong and waste time trying to debug that, only to discover that in fact it was your redefined open function that caused the problem. Then you'll have to revisit this issue, put the open function back the way it was, and do what you should have done.

Do it right in the first place. Spend the extra fifteen seconds per script and do the search and replace. It will save you a lot of time.