Re[6]: Finding @INC

2001-06-28 Thread Maxim Berlin

Hello Randal,

Thursday, June 28, 2001, Randal L. Schwartz [EMAIL PROTECTED] wrote:


RLS NO NO.  That doesn't work.  All of those unshifts are executed REGARDLESS
RLS of the $OS type.
[...]
Randal, thank you for your patience and examples, but please do not
explain how BEGIN works again. I know that.

RLS So, Maxim, YOU are demonstrating the very reason I would flunk your
RLS code.  It *doesn't* work!
my code is not absolytely correct, but it *works*. In
*this* case form is more important than contents for *me*.

RLS BEGIN { unshift @INC, ... } is reducible to the standard idiom
RLS of use lib ..., and should used in preference.
I understand, that beginners@ isn't right place for my example and our
discussion, but i took a part from very old (but still
working) perl script; yes, i should have checked that part before
sending, but (sigh...) nobody is perfect.
my apologies.

Best wishes,
 Maximmailto:[EMAIL PROTECTED]





Re[6]: Finding @INC

2001-06-28 Thread Peter Scott

At 02:24 AM 6/29/01 +0400, Maxim Berlin wrote:
Thursday, June 28, 2001, Randal L. Schwartz [EMAIL PROTECTED] wrote:

RLS NO NO.  That doesn't work.  All of those unshifts are executed REGARDLESS
RLS of the $OS type.
[...]
Randal, thank you for your patience and examples, but please do not
explain how BEGIN works again. I know that.

RLS So, Maxim, YOU are demonstrating the very reason I would flunk your
RLS code.  It *doesn't* work!
my code is not absolytely correct, but it *works*. In
*this* case form is more important than contents for *me*.

Your idea of working needs some revision.  Your code may produce the 
results you want, but it is structured in a way that implies you don't 
understand what it's doing, or you wouldn't have done it that way.  That's 
unhelpful to beginners in particular, and you would be well served by 
looking again to see how Randal's analysis can be used to improve your use 
of Perl.  This is not just a matter of style.  I could and would have made 
the same arguments, but Randal was faster and more articulate.

--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com




Re: Finding @INC

2001-06-28 Thread Michael Fowler

On Fri, Jun 29, 2001 at 02:24:56AM +0400, Maxim Berlin wrote:
 Thursday, June 28, 2001, Randal L. Schwartz [EMAIL PROTECTED] wrote:
 
 RLS NO NO.  That doesn't work.  All of those unshifts are executed REGARDLESS
 RLS of the $OS type.
 [...]
 Randal, thank you for your patience and examples, but please do not
 explain how BEGIN works again. I know that.
 
 RLS So, Maxim, YOU are demonstrating the very reason I would flunk your
 RLS code.  It *doesn't* work!
 my code is not absolytely correct, but it *works*. In
 *this* case form is more important than contents for *me*.

I don't understand, if you wanted all of those paths in @INC, why put them
in conditionals?  Why didn't you do something along the lines of:

# I don't recall exactly what the original code was, so the specifics
# may be a bit off.
BEGIN { unshift(@INC, C:\\winnt, /usr/local, /usr) }

if ($OSNAME eq 'nt') {
`del ...`;
} elsif ($OSNAME eq 'linux') {
`rm -rf ...`;
} elsif ($OSNAME eq 'freebsd') {
`rm -rf ...`;
}

That is, effectively, what you achieve by having BEGIN blocks in each
conditional.  This certainly doesn't look like what you intended.


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--



Re: Re[6]: Finding @INC

2001-06-28 Thread Randal L. Schwartz

 Maxim == Maxim Berlin [EMAIL PROTECTED] writes:

Maxim Randal, thank you for your patience and examples, but please do not
Maxim explain how BEGIN works again. I know that.

No, you don't.  I'll stop here, I'm apparently beating my head
against your brick wall.

And judging from the other responses you got on this thread, I'm
not off my rocker.  One of us has additional supporters.  One of us
doesn't.  There's a big clue there.

-- 
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!



Re: Finding @INC

2001-06-27 Thread Maxim Berlin

Hello Dennis,

Tuesday, June 26, 2001, Dennis Fox [EMAIL PROTECTED] wrote:

DF My difficulty is that I don't understand how to modify @INC to
DF include the non-standard locations, so that I don't have to have the user
DF supply commandline arguments each time the script is needed.

example:

if ( $OS ne NT )
{
  BEGIN { unshift(@INC,/usr/local/etc); }
  require config.backup.pl;
}


Best wishes,
 Maximmailto:[EMAIL PROTECTED]





Re: Finding @INC

2001-06-27 Thread Hasanuddin Tamir

On Wed, 27 Jun 2001, Maxim Berlin [EMAIL PROTECTED] wrote,

 Hello Dennis,

 Tuesday, June 26, 2001, Dennis Fox [EMAIL PROTECTED] wrote:

 DF My difficulty is that I don't understand how to modify @INC to
 DF include the non-standard locations, so that I don't have to have the user
 DF supply commandline arguments each time the script is needed.

 example:

 if ( $OS ne NT )
 {
   BEGIN { unshift(@INC,/usr/local/etc); }
   require config.backup.pl;
 }

The BEGIN blocks always execute first no matter where you put them.

#!/usr/bin/perl -w

print __LINE__, : Am I the first?\n;

if (1) {
BEGIN {
print __LINE__, : No, I am the one\n;
}
print __LINE__, : Then I am the last\n;
}

__END__

7: No, I am the one
3: Am I the first?
9: Then I am the last

-- 
s::a::n-http(www.trabas.com)




Re: Finding @INC

2001-06-27 Thread Jos Boumans

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

concider:
use lib (../foo);

rather than:

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

perldoc lib for more info

hth
Jos Boumans


Maxim Berlin wrote:

 Hello Dennis,

 Tuesday, June 26, 2001, Dennis Fox [EMAIL PROTECTED] wrote:

 DF My difficulty is that I don't understand how to modify @INC to
 DF include the non-standard locations, so that I don't have to have the user
 DF supply commandline arguments each time the script is needed.

 example:

 if ( $OS ne NT )
 {
   BEGIN { unshift(@INC,/usr/local/etc); }
   require config.backup.pl;
 }

 Best wishes,
  Maximmailto:[EMAIL PROTECTED]




Re[2]: Finding @INC

2001-06-27 Thread 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: Finding @INC

2001-06-27 Thread Jos Boumans

because push @INC is a runtime statement,
use lib is a compile time statement

meaning you'll be alerted if the dir doesnt exist, or something else goes wrong at the
moment you start your script, rather then it dying half way when not findin a file.


hth
Jos Boumans

Maxim Berlin wrote:

 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

2001-06-27 Thread 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!



Finding @INC

2001-06-26 Thread Dennis Fox

Greetings all,
I am doing work on a system where custom Perl Modules have been
installed in at least two non-standard places -- no, not by me ;-).  Since
the primary application on this system is to be replicated on several
other boxes, I am trying to write a script that will find and identify all
installed PMs on a box so that I can make sure that all the versions match
between those boxes.
I quickly found the pmdesc script by [EMAIL PROTECTED] in the
Cookbook, and it finds all the standard PMs quite nicely.
My difficulty is that I don't understand how to modify @INC to
include the non-standard locations, so that I don't have to have the user
supply commandline arguments each time the script is needed.

Any and all hints gratefully acknowledged and pursued!  Thanks.


DENNIS Bass Dude FOX | [EMAIL PROTECTED]
Bureaucracy is the art of making the possible impossible
--Javier Pascual Salcedo





RE: Finding @INC

2001-06-26 Thread Peter Cornelius

 
   My difficulty is that I don't understand how to modify @INC to
  include the non-standard locations, so that I don't have to 
  have the user
  supply commandline arguments each time the script is needed.
 
 You want the 'use lib /non/statdard/lib;' directive.  You 
 can get more info from 'perldoc lib'.
 
 



Re: Finding @INC

2001-06-26 Thread Michael Fowler

On Tue, Jun 26, 2001 at 09:44:13AM -0500, Dennis Fox wrote:
   My difficulty is that I don't understand how to modify @INC to
 include the non-standard locations, so that I don't have to have the user
 supply commandline arguments each time the script is needed.

perldoc -q 'my own module'

OR

http://www.perldoc.com/perl5.6/pod/perlfaq8.html#How%20do%20I%20keep%20my%20own%20module%2flibrary%20directory%3f

(boy, perldoc.com could use some sort of compressed anchor names..)


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--