Re[2]: Finding @INC

[Maxim Berlin]

Hello Jos,

Wednesday, June 27, 2001, Jos Boumans [EMAIL PROTECTED] wrote:

JB Please use the the 'use lib' pragma, rather then fiddling with @INC

JB concider:
JB use lib (../foo);

JB rather than:

JB BEGIN: { push @INC, '../foo' }

JB perldoc lib for more info

according to perldoc lib:

   use lib LIST;

   is almost the same as saying

   BEGIN { unshift(@INC, LIST) }

   For each directory in LIST (called $dir here) the lib mod-
   ule also checks to see if a directory called $dir/$arch-
   name/auto exists.  If so the $dir/$archname directory is
   assumed to be a corresponding architecture specific direc-
   tory and is added to @INC in front of $dir.

for my configs, i don't need (and don't have) $dir/$archname/auto directories, so i
still use

   BEGIN { unshift(@INC,/usr/local/etc); }

am i wrong?

Best wishes,
 Maximmailto:[EMAIL PROTECTED]

Re: Re[2]: Finding @INC

[Randal L. Schwartz]

 Maxim == Maxim Berlin [EMAIL PROTECTED] writes:

Maxim for my configs, i don't need (and don't have)
Maxim $dir/$archname/auto directories, so i still use

 BEGIN { unshift(@INC,/usr/local/etc); }

Maxim am i wrong?

You are typing too much.  In a code review, I'd flag that as a warning
item, as in why does he open-code a standard use-lib?  It's more
typing, less functionality, and makes me wonder if there's some reason
you *couldn't* have done it the standard way, as in you had an arch
directory that you *didn't* want installed.

Now, if there's something else inside that BEGIN block, like:

BEGIN {
  $dir = $DEBUG ? /my/private/dir : /usr/local/etc;
  unshift @INC, $dir;
}

then you're perfectly entitled to your BEGIN block.  But not when it's
standalone.  That wouldn't be a fatal in a code review (unless it was
inside a conditional, as I said in my other message), but it's flagged
as a warning fix.

Never open-code something... people smell trouble.  Sorry, 24 years of
professional programming and a half-dozen years before that of
tinkering have lead me to some pretty stiff ideas about how people can
screw up when maintaining your code, and I'm probably not gonna budge
on that.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!