lib.pm module pollutes @INC with duplicates under mod_perl #460
Comments
From [email protected]A minor correction I've made to the module easily resolves the problem Modify the import() method as follows (my changes shown with a leading sub import { | map(++$inc{$_}, @INC); foreach (reverse @_) { -- |
From @gsarOn Tue, 31 Aug 1999 12:30:49 PDT, Tod Irwin wrote:
I've changed your fix slightly to keep any new entries at the Sarathy Inline Patch-----------------------------------8<-----------------------------------
Change 4327 by gsar@auger on 1999/10/10 02:23:52
avoid duplicates in @INC, they cause leaks in mod_perl etc
(suggested by Tod Irwin <[email protected]>)
Affected files ...
... //depot/perl/lib/lib.pm#7 edit
Differences ...
==== //depot/perl/lib/lib.pm#7 (text) ====
Index: perl/lib/lib.pm
--- perl/lib/lib.pm.~1~ Sat Oct 9 19:25:43 1999
+++ perl/lib/lib.pm Sat Oct 9 19:25:43 1999
@@ -10,13 +10,12 @@
sub import {
shift;
+
+ my %names;
foreach (reverse @_) {
- ## Ignore this if not defined.
- next unless defined($_);
if ($_ eq '') {
require Carp;
Carp::carp("Empty compile time value given to use lib");
- # at foo.pl line ...
}
if (-e && ! -d _) {
require Carp;
@@ -29,27 +28,23 @@
unshift(@INC, "$_/$archname") if -d "$_/$archname/auto";
unshift(@INC, "$_/$archname/$]") if -d "$_/$archname/$]/auto";
}
+ # remove trailing duplicates
+ @INC = grep { ++$names{$_} == 1 } @INC;
}
}
sub unimport {
shift;
- my $mode = shift if $_[0] =~ m/^:[A-Z]+/;
my %names;
- foreach(@_) {
+ foreach (@_) {
++$names{$_};
++$names{"$_/$archname"} if -d "$_/$archname/auto";
}
- if ($mode and $mode eq ':ALL') {
- # Remove ALL instances of each named directory.
- @INC = grep { !exists $names{$_} } @INC;
- } else {
- # Remove INITIAL instance(s) of each named directory.
- @INC = grep { --$names{$_} < 0 } @INC;
- }
+ # Remove ALL instances of each named directory.
+ @INC = grep { !exists $names{$_} } @INC;
}
1;
@@ -74,7 +69,7 @@
that later C<use> or C<require> statements will find modules which are
not located on perl's default search path.
-=head2 ADDING DIRECTORIES TO @INC
+=head2 Adding directories to @INC
The parameters to C<use lib> are added to the start of the perl search
path. Saying
@@ -90,10 +85,10 @@
If so the $dir/$archname directory is assumed to be a corresponding
architecture specific directory and is added to @INC in front of $dir.
-If LIST includes both $dir and $dir/$archname then $dir/$archname will
-be added to @INC twice (if $dir/$archname/auto exists).
+To avoid memory leaks, all trailing duplicate entries in @INC are
+removed.
-=head2 DELETING DIRECTORIES FROM @INC
+=head2 Deleting directories from @INC
You should normally only add directories to @INC. If you need to
delete directories from @INC take care to only delete those which you
@@ -101,25 +96,16 @@
in your script. Other modules may have added directories which they
need for correct operation.
-By default the C<no lib> statement deletes the I<first> instance of
-each named directory from @INC. To delete multiple instances of the
-same name from @INC you can specify the name multiple times.
+The C<no lib> statement deletes all instances of each named directory
+from @INC.
-To delete I<all> instances of I<all> the specified names from @INC you can
-specify ':ALL' as the first parameter of C<no lib>. For example:
-
- no lib qw(:ALL .);
-
For each directory in LIST (called $dir here) the lib module also
checks to see if a directory called $dir/$archname/auto exists.
If so the $dir/$archname directory is assumed to be a corresponding
architecture specific directory and is also deleted from @INC.
-If LIST includes both $dir and $dir/$archname then $dir/$archname will
-be deleted from @INC twice (if $dir/$archname/auto exists).
+=head2 Restoring original @INC
-=head2 RESTORING ORIGINAL @INC
-
When the lib module is first loaded it records the current value of @INC
in an array C<@lib::ORIG_INC>. To restore @INC to that value you
can say
@@ -136,4 +122,3 @@
Tim Bunce, 2nd June 1995.
=cut
-
End of Patch. |
From [Unknown Contact. See original ticket]Gurusamy Sarathy <gsar@ActiveState.com> wrote
This change needs to be considered carefully. It removes a And surely mod_perl should be cleaning up @INC anyway. What happens Mike Guy |
From @gsarOn Mon, 11 Oct 1999 17:46:00 BST, "M.J.T. Guy" wrote:
I did consider it very carefully, and came to the conclusion that Sarathy |
From [Unknown Contact. See original ticket]Gurusamy Sarathy <gsar@ActiveState.com> wrote
OK - sorry to have implied otherwise. But I would normally
What's so difficult about it? I always assumed the intended style use lib "my/private/library/for/this/module/only"; Where's the difficulty in ordering? But, as I said, I've never felt tempted to use this feature. So I Mike Guy |
From [Unknown Contact. See original ticket]Gurusamy Sarathy <gsar@ActiveState.com> writes:
Why is that so hard? In almost all cases use lib only occurs in the top I have more then once done: use lib "/somepath/in/inc/already"; Just to make it be searched before it would otherwise have been. This "trick" is particularly handy in Makefile.PLs - e.g. Tk's does use lib '.'; To grab ./Tk/MMutil.pm So I don't mind duplicates being pruned but the ordering should -- |
From [Unknown Contact. See original ticket]
Mike> Gurusamy Sarathy <gsar@ActiveState.com> wrote Mike> OK - sorry to have implied otherwise. But I would normally >> and came to the conclusion that that "feature" is impossible to Mike> What's so difficult about it? I always assumed the intended Mike> use lib "my/private/library/for/this/module/only"; Mike> Where's the difficulty in ordering? Mike> But, as I said, I've never felt tempted to use this feature. Actually, I've used this feature, and have been tearing my head out I might suggest that what are needed are new functions within the lib Unfortunately, the structure and usage of lib.pm argue against having use lib::ensure; no lib::ensure; use lib::append; Do note that I've got a first hack this coded up, and will be happy to |
From @gsarOn Mon, 11 Oct 1999 18:59:14 BST, "M.J.T. Guy" wrote:
This still works after the change, assuming Mymodule* don't
I was referring to behavior that depended on the order in which Sarathy |
From @gsarOn Mon, 11 Oct 1999 19:29:05 BST, Nick Ing-Simmons wrote:
Yes, that's exactly what happens. Sarathy |
From @gsarOn Mon, 11 Oct 1999 19:29:05 BST, Nick Ing-Simmons wrote:
FWIW, I consider it poor style to write *modules* that contain Sarathy |
From [Unknown Contact. See original ticket]Brent B. Powers <p5p@b2pi.com> writes:
Rather than messing with lib.pm with these 'pragmas' why not just use lib::ensure '/foo/bar'; -- |
From [Unknown Contact. See original ticket]
Nick> Brent B. Powers <p5p@b2pi.com> writes: Nick> Rather than messing with lib.pm with these 'pragmas' why not Nick> use lib::ensure '/foo/bar'; The combinations get exasperating. (Since ensure implies unique, there use lib::unique::append '/foo/bar'; # ?? |
From [Unknown Contact. See original ticket]Brent B . Powers <bpowers@ms.com> writes:
says you ;-)
Hmm. The unique bit can be done after-the-fact on another call: Just because lib does not allow for extensions does not mean you cannot use lib::hackery push => '/foo/bar', unshift => '/tmp/wurble', unique; Hey - what about allowing perl code : BEGIN -- |
From [Unknown Contact. See original ticket]
Brent B . Powers <bpowers@ms.com> writes:
Nick> says you ;-) Well, me, and the demons telling me to kill the president (They happen
Nick> Hmm. The unique bit can be done after-the-fact on another call: Nick> Just because lib does not allow for extensions does not mean Nick> use lib::hackery push => '/foo/bar', unshift => '/tmp/wurble', unique; Ummmm, ughh. Certainly someone else could write lib::hackery. I was Nick> Hey - what about allowing perl code : Nick> BEGIN May I presume that that's a joke? |
From [Unknown Contact. See original ticket] |
From @vanstynIn <199910111905.MAA05725@activestate.com>, Gurusamy Sarathy writes: I'm not particularly defending the practice, but in my current work all This is very useful in this particular environment, not least because Hugo |
From [Unknown Contact. See original ticket]Good afternoon Sarthy: Since you are contemplating changes (or have already done so), The environment variable PERL5LIB also appends paths to Do you want the 'use lib' statement to take precedence over the I have seen/heard of two uses of the PERL5LIB variable: 1. Set path to modules to be used by a set of scripts. The existing functionality really only supports #1 when One can't always install modules in the site_perl directories Given this type of environment, it would be nice if the documented Could we at least write up the intentions of the interaction between Adam Krolnik |
Migrated from rt.perl.org#1301 (status was 'resolved')
Searchable as RT1301$
The text was updated successfully, but these errors were encountered: