[22775] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4996 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 16 18:05:56 2003

Date: Fri, 16 May 2003 15:05:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Fri, 16 May 2003     Volume: 10 Number: 4996

Today's topics:
    Re: [The/My] trouble with Perl <bkennedy@hmsonline.com>
    Re: A script that can (conditionally) return 3 differen <stevenm@bogus.blackwater-pacific.com>
    Re: A script that can (conditionally) return 3 differen <stevenm@bogus.blackwater-pacific.com>
    Re: A script that can (conditionally) return 3 differen (A Epstein)
    Re: A script that can (conditionally) return 3 differen <emschwar@pobox.com>
    Re: compile error for Time-HoRes-1.47 using perl 5.8.0 <rgarciasuarez@free.fr>
    Re: concise code competition <mpapec@yahoo.com>
        curses and memory <ah@siol.net>
    Re: Dynamic Module Installation <palladium@spinn.net>
    Re: Exporter not doing what I expect <michael.p.broida@boeing.com>
    Re: Exporter not doing what I expect <noreply@gunnar.cc>
    Re: Exporter not doing what I expect <michael.p.broida@boeing.com>
    Re: Exporter not doing what I expect <rick.delaney@rogers.com>
    Re: Exporter not doing what I expect (Jay Tilton)
    Re: Exporter not doing what I expect <michael.p.broida@boeing.com>
    Re: Exporter not doing what I expect <michael.p.broida@boeing.com>
    Re: Exporter not doing what I expect <michael.p.broida@boeing.com>
    Re: Exporter not doing what I expect <noreply@gunnar.cc>
        fchown and fchmod (Jason McManus)
    Re: fchown and fchmod <rick.delaney@rogers.com>
    Re: find and replace script... please help. (Veky)
        how do i hide a password? (bill j)
        oddity per sort internal (Xah Lee)
    Re: oddity per sort internal <skuo@mtwhitney.nsc.com>
    Re: oddity per sort internal (Jay Tilton)
    Re: oddity per sort internal <usenet@tinita.de>
    Re: one liner in command line <nospam@raytheon.com>
        possible bug in m// ? (dan baker)
    Re: possible bug in m// ? <mpapec@yahoo.com>
    Re: possible bug in m// ? <nobody@dev.null>
        Unicode UTF8/UTF16 Regexp Problem (Deltran Municipa)
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 16 May 2003 17:22:41 -0400
From: "Ben Kennedy" <bkennedy@hmsonline.com>
Subject: Re: [The/My] trouble with Perl
Message-Id: <t_acnYOAXNw5y1ijXTWcrg@giganews.com>


"Henk van Bree" <geenspam@geenspam.biz> wrote in message
news:3ec28f75$0$49117$e4fe514c@news.xs4all.nl...
>
>
> I know good work is being done on Perl version 6, but may I input a
> suggestion for Perl version 7:
>
>         **Let Perl 7 have a native GUI widget set!**
>
> So far I've tried to get Qt, WxWindows, Gtk and/or Tk to work, with
several
> degrees of succes but it just doesn't work everytime.

Even if Perl didn't have a perfectly functional/portable GUI toolkit (Tk),
this would be a mistake.  Do we really need more operators cluttering up
perlfunc?  If anything, more stuff should be ripped out of the core and
placed into modules, especially since we're way beyond running solely on
Unix.  While we're at it, let's take out formats as well.  Also note that
just because something is "native", doesn't make it more portable or easier
to install - there'd be all the same difficulties compiling perl with
"-DUSE_GUI" as there currently are compiling Tk.

--Ben Kennedy




------------------------------

Date: Fri, 16 May 2003 12:18:11 -0700
From: Steve May <stevenm@bogus.blackwater-pacific.com>
Subject: Re: A script that can (conditionally) return 3 different exit codes
Message-Id: <ba3d5l$ofu$1@quark.scn.rain.com>

A Epstein wrote:
> I have to write a script that exists with exit code 0 on success, exit
> code 1 on a user interactivity error (such as misspelling a word), and
> exit code 2 if there is a system error that causes the script to fail.
> The first two codes (0, 1) are easy.  I just check if the user makes a
> mistake and exit with 1.  Otherwise it will exit with 0.  But what
> about the exiting with code 2 if there is a system problem?
> 
> Someone else's program or script will have to pick on these codes
> after calling my script so this is important (for me :)).
> 
> Any suggestions?
> 
> Thanks,
> A E

Looking at the other posts, either I missed your point or some of
theirs, but I *think* you are looking for a way to return a specific
value of '2' and only '2' upon a runtime error....

That being true, a simple solution might be placing this right at the
top of your script:

$SIG{'__DIE__'} = $SIG{'__WARN__'} = sub { exit 2; }


Not real helpful for diagnosis, of course. :-)

s.



------------------------------

Date: Fri, 16 May 2003 12:25:19 -0700
From: Steve May <stevenm@bogus.blackwater-pacific.com>
Subject: Re: A script that can (conditionally) return 3 different exit codes
Message-Id: <ba3dj1$p2c$1@quark.scn.rain.com>

Steve May wrote:
> A Epstein wrote:
> 
>> I have to write a script that exists with exit code 0 on success, exit
>> code 1 on a user interactivity error (such as misspelling a word), and
>> exit code 2 if there is a system error that causes the script to fail.
>> The first two codes (0, 1) are easy.  I just check if the user makes a
>> mistake and exit with 1.  Otherwise it will exit with 0.  But what
>> about the exiting with code 2 if there is a system problem?
>>
>> Someone else's program or script will have to pick on these codes
>> after calling my script so this is important (for me :)).
>>
>> Any suggestions?
>>
>> Thanks,
>> A E
> 
> 
> Looking at the other posts, either I missed your point or some of
> theirs, but I *think* you are looking for a way to return a specific
> value of '2' and only '2' upon a runtime error....
> 
> That being true, a simple solution might be placing this right at the
> top of your script:
> 
> $SIG{'__DIE__'} = $SIG{'__WARN__'} = sub { exit 2; }
> 
> 
> Not real helpful for diagnosis, of course. :-)
> 
> s.
> 
  Oops!

$SIG{'__DIE__'} = $SIG{'__WARN__'} = sub { exit 2; };

Forgot the semi-colon.  Bad Steve....

s.



------------------------------

Date: 16 May 2003 14:09:11 -0700
From: epstein_asaf@emc.com (A Epstein)
Subject: Re: A script that can (conditionally) return 3 different exit codes
Message-Id: <a82b1086.0305161309.671dd53a@posting.google.com>

Brian McCauley <nobull@mail.com> wrote in message news:<u93cjeg6md.fsf@wcl-l.bham.ac.uk>...
> epstein_asaf@emc.com (A Epstein) writes:
> 
> > I have to write a script that exists with exit code 0 on success, exit
> > code 1 on a user interactivity error (such as misspelling a word), and
> > exit code 2 if there is a system error that causes the script to fail.
> > The first two codes (0, 1) are easy.  I just check if the user makes a
> > mistake and exit with 1.  Otherwise it will exit with 0.  But what
> > about the exiting with code 2 if there is a system problem?
> 
> I'm not sure I understand what you are asking.  If indeed you are
> asking anything.
> 
> The exit code from perl in the event of abnornal termination is as
> described in 'perldoc -f die'.

Wow you guys!  That was indeed humiliating.  I am perfectly aware of
how to write 'exit 2' and of the die function, the $! $? special
variables and much more.  all i wanted to know is how to determine of
indeed i am in a situation were 'exit 2' is needed.  In other words,
has there been an error that would require me to exit with this code. 
I mean do I just have to go through my code and add a bunch of 'or die
"..."' statements to every place I can concieve a failure might
happen?
Maybe this is all silly but the fact remains:
I need to:
exit 0 if all goes well,
exit 1 if user makes a mistake,
exit 2 if something is wrong, system-wise, that causes a failure.

Thanks in advance for those who still have patience to help me.
Oh, and there's no need be condesending to try and take away my
dignity.  I'm fresh out :)

A E


------------------------------

Date: 16 May 2003 15:42:04 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: A script that can (conditionally) return 3 different exit codes
Message-Id: <etofzned0wj.fsf@wormtongue.emschwar>

epstein_asaf@emc.com (A Epstein) writes:
> Wow you guys!  That was indeed humiliating.

Not being Brian I can't say for sure, but it didn't seem to be
intended so.

>  I am perfectly aware of
> how to write 'exit 2' and of the die function, the $! $? special
> variables and much more.  all i wanted to know is how to determine of
> indeed i am in a situation were 'exit 2' is needed.

See, this is where I get humiliating. :)  That's called
"programming".  There's no Perl magic variable that's set to a value
if "something is wrong, system-wise, that causes a failure" because
you still haven't defined what "wrong" is, in the context of your
program, what type of system you're referring to (Operating system--
which one?  Webserver-- ditto?  some custom AI framework) and how you
can defined what "a failure" is.

We're not psychics here.  You're throwing out a lot of very vague
words as if they had concrete meanings, and you seem to be expecting
us to magically determine somehow what you mean by them.

>  In other words,
> has there been an error that would require me to exit with this
> code. 

Dunno.  You haven't said anything about what sort of error that might
be.  The answer to that could be anything from "Check the return value
of system()" to "invoke a stochastic error detection mechanism using the
value of the last three attempts to run this code" to "observe the
height of the mushroom cloud, and log an error if it's > 300M higher
than the last bomb we exploded".

> I mean do I just have to go through my code and add a bunch of 'or die
> "..."' statements to every place I can concieve a failure might
> happen?

That's one way.  There are many others.  What is the actual, concrete,
specific problem you're trying to solve?

> Thanks in advance for those who still have patience to help me.
> Oh, and there's no need be condesending to try and take away my
> dignity.  I'm fresh out :)

No condescension here; if you find any, you're reading more into it
than I'm putting out.  Your posts, however, haven't had much more
detail than, "I want to detect errors.  How do I do that?"  This is
so vague, I hope you can see that there's no possible way to answer
that without repeating literally reams of information from software
testing literature.  Get specific and precise, and we might be able
to help you out.

-=Eric
-- 
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
		-- Blair Houghton.


------------------------------

Date: 16 May 2003 20:04:47 GMT
From: Rafael Garcia-Suarez <rgarciasuarez@free.fr>
Subject: Re: compile error for Time-HoRes-1.47 using perl 5.8.0
Message-Id: <slrnbcahdv.73l.rgarciasuarez@dat.local>

Eric wrote in comp.lang.perl.misc :
> Download perl 5.8.0 from CPAN and compiled it on RH 9.0. Recompile
> Time-HiRes-1.47 and the compilation was sucessfull. It seems to
> suggest perl 5.8.0-88, RH 9.0 distribution not generating the Makefile
> correctly. Looking at the Makefile generated by perl 5.8.0, RH 9
> distribution, it either mis quoted some string or missing bits and
> peices of directories assingned to variable.

Yes, that's correct, since RH 9.0 comes with a modified perl 5.8.0,
containing further bug fixes.

The workaround for your original problem is probably to execute the
Makefile.PL and the make/make test phase with the locale set to LC_ALL=C.

-- 
Undergraduate is not *NIX


------------------------------

Date: Fri, 16 May 2003 21:31:54 +0200
From: Matija Papec <mpapec@yahoo.com>
Subject: Re: concise code competition
Message-Id: <m2facvklkmfnfqf3tii6cd2upjksqg755n@4ax.com>

X-Ftn-To: joeri 

"joeri" <jvandervloet@hotmail.com> wrote:
>Hi folks,
>
>we're having ourselves a little competition here
>on making the following code as concise as possible,
>without loosing any performance. 

You probably can't loose performance but readability is another thing.

(!-e || -z) and open(OUT, ">$_") for "$dir/output/$_";

;)

>Here's the code as it is now:
>
>    opendir(DIR, $dir="c:/dir") or die "$!";
>    mkdir("$dir/output");

  opendir(DIR, $dir="c:/dir") or die $!;
  mkdir "$dir/output";
  for (grep /\.txt$/, readdir DIR) {
    open(FILE, "$dir/$_") or die $!;
    
    for ("$dir/output/$_") {
     	open(OUT, ">$_") if !-e || -z;
    }
    tr/=/\n/, print OUT while <FILE>;
    close OUT;
    close FILE;
  }
  closedir DIR;


-- 
Matija


------------------------------

Date: Fri, 16 May 2003 18:55:55 GMT
From: Andrej Hocevar <ah@siol.net>
Subject: curses and memory
Message-Id: <slrnbcad72.4ko.ah@sonet.utopija.linux>

Hello.

I've just completed my first program with curses and I've observed an
interesting phenomenon, at least to me it seems so. I let the program
draw something like a menu where the user can scroll through with the
arrow keys. Each line there is represented by a separate pad. As far
as I can tell, it works OK.

But looking at the info top gave me, I found this out: the more
I scroll through that menu, the bigger the "SIZE" field gets.
Now why is this? I thought it's probably some kind of a memory leak
or something, so I tried to fix it. Here's the interesting part -- I
could decrease the comsumption a lot by deleting all those pads with
delwin() and then recreating all of them again. 

Is this logical? 

Thanks,

    andrej

-- 
echo ${girl_name} > /etc/dumpdates


------------------------------

Date: Fri, 16 May 2003 13:08:48 -0600
From: "Rodney" <palladium@spinn.net>
Subject: Re: Dynamic Module Installation
Message-Id: <vcadrjbfeelee7@corp.supernews.com>

"Rodney" <palladium@spinn.net> wrote in message
news:vca6mti5hqa54e@corp.supernews.com...
> Hey perl Gurus;
> I have a design question. I noticed (perldoc CPAN) mentions that the only
> stable interface to CPAN is shell. I was wondering if I am smoking crack
> here. I want to create a CPAN mirror internally (firewall issues). And
then
> have my clients grab their modules dynamically from my mirror based upon
the
> use clause within each script sent to the client. for instance, if I use
> XML::Simple I want the client to connect to my mirror and download the
> XML::Simple and all dependant modules required for XML::Simple. This is
for
> an ESM project that keeps all the clients configured the same for Change
> Control reasons. I know that there is a programmers interface to CPAN, but
> if it is flaky, I would rather just manually copy the proper packages to
the
> client at script installation time, (I have (10000+) clients.).
>
> Any Thoughts?
>
> Thanks,
> Rod
>
I guess I should clarify a few things. I am using a w32 service I wrote
using perl that listens on a socket for incoming connections from my unix
server. The server sends the script to be executed through the socket, which
writes it to disk and executes it. Then returns exit code to the server, in
an attempt to streamline the installation and management of that many perl
clients, I don't want to install a full version of  perl unless required to
the clients.

Hope that made sense.

Rod




------------------------------

Date: Fri, 16 May 2003 17:55:45 GMT
From: "Michael P. Broida" <michael.p.broida@boeing.com>
Subject: Re: Exporter not doing what I expect
Message-Id: <3EC52621.E06CC4D9@boeing.com>

"Michael P. Broida" wrote:
> 
> Hi!
>         OK, it's probably something I'm not doing correctly, but...
> 
>         I've setup XYZ.pm as a package.  It contains (among other things):
>                 use strict;
>                 use warnings;
>                 require Exporter
>                 my @ISA    = qw(Exporter);
>                 my @EXPORT = qw(FunctionOne, FunctionTwo);
> 
>         From reading (and re-reading and re-reading) the Camel book, it
>         seems that this SHOULD limit the "users" of XYZ to being able to
>         access ONLY those functions/variables that are in the EXPORT list.
> 
>         But that's not happening.  The "users" can call ANY function in
>         XYZ with no errors/warnings.


    Oops, found out why it does this.  And yes, it's my fault.  :)

    On the fifth or sixth rereading of the description of Exporter,
    I finally spotted the statement that if a user uses the syntax:
	  PackageName::PackageItem
    they effectively override the Exporter limits.  Yep, that's
    what I was doing.

    So, I'll just remove all those "PackageName::" bits and the limits
    should kick in just fine.

         Mike


------------------------------

Date: Fri, 16 May 2003 20:47:57 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Exporter not doing what I expect
Message-Id: <ba3bp2$o6ioq$1@ID-184292.news.dfncis.de>

Michael P. Broida wrote:
> 	From reading (and re-reading and re-reading) the Camel book, it
> 	seems that this SHOULD limit the "users" of XYZ to being able to
> 	access ONLY those functions/variables that are in the EXPORT list.

Note that the purpose of exporting things is not to _limit_ access to 
anything that is not exported. Exporting the name of a function or 
variable may make that function or variable available in some other 
package/namespace without a need to qualify them.








> 
> 	But that's not happening.  The "users" can call ANY function in
> 	XYZ with no errors/warnings.
> 
> 	The "users" of XYZ (my main Perl script and another package) both
> 	have (among other things):
> 
> 		use strict;
> 		use warnings;
> 		use XYZ;
> 
> 	If I comment out all of the Exporter stuff in XYZ.pm, then they
> 	can't call ANY of the XYZ functions.  This I expected.
> 
> 	I know that I -could- be explict on the "use XYZ" statement and
> 	list all the functions to be used.
> 
> 	But if the "users" can get full access to everything without
> 	listing them, what good is the EXPORT list in XYZ.pm anyway??
> 	It seems to be exporting EVERYTHING even if the list does not
> 	contain everything.
> 
> 		Mike


-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl



------------------------------

Date: Fri, 16 May 2003 18:41:52 GMT
From: "Michael P. Broida" <michael.p.broida@boeing.com>
Subject: Re: Exporter not doing what I expect
Message-Id: <3EC530F0.CEE6EFB0@boeing.com>

Hi again!  (Replying to myself, but slightly different problem.)

Well, I thought I had fixed it, but it's still not correct.  Need some more help.

I now have this:

In XYZ.pm:
	package XYZ;
	use strict;
	use warnings;
	require Exporter;
	my @ISA = qw(Exporter);
	my @EXPORT = qw();
	use vars qw($VarONE, $VarTWO);  # Next line didn't work without this one
	my @EXPORT_OK = qw(FuncONE, FuncTWO, $VarONE, $VarTWO);
	...code for FuncONE, FuncTWO, FuncTHREE then follow...
   The above supposedly makes it mandatory for the "user" to either
   ignore Export/import and explicitly call the functions like:
	XYZ::FuncONE()
   or to explicitly import the names to use like:
	use XYZ qw(FuncONE);
   then later just call it without the qualifier:
	FuncONE();

In main script ABC.pl:
	use strict;
	use warnings;
	use XYZ qw(FuncONE, FuncTWO, $VarONE, $VarTWO);
	#Later...
	call to FuncONE;
	call to FuncTWO;
	call to FuncTHREE;  # function in package XYZ but NOT exported
	use of $VarONE;
	use of $VarTWO;

I get NO complaints about the use of FuncTHREE even though it is
not exported or imported.  This doesn't seem correct to me.
What's the use of the Exporter if every function is available
without Exporting or importing its name?

I get errors that the uses of $VarONE and $VarTWO need explicit
package names specified.  This doesn't seem correct to me, either.
The "use XYZ" statement already tells where that variable comes from.
Why do I have to specify the package name for variables when I don't
for Function names exported/imported in the same manner???

Basically, Exporter does NOT seem to be limiting what it should limit,
but is limiting what it should NOT limit.

Please set me straight on this.  Thanks!

	Mike


------------------------------

Date: Fri, 16 May 2003 19:27:43 GMT
From: Rick Delaney <rick.delaney@rogers.com>
Subject: Re: Exporter not doing what I expect
Message-Id: <m38yt6n13l.fsf@biff.bort.ca>

"Michael P. Broida" <michael.p.broida@boeing.com> writes:

> Hi again!  (Replying to myself, but slightly different problem.)
> 
> Well, I thought I had fixed it, but it's still not correct.  Need some more help.
> 
> I now have this:
> 
> In XYZ.pm:
> 	package XYZ;
> 	use strict;
> 	use warnings;
> 	require Exporter;
> 	my @ISA = qw(Exporter);
> 	my @EXPORT = qw();
> 	use vars qw($VarONE, $VarTWO);  # Next line didn't work without this one
> 	my @EXPORT_OK = qw(FuncONE, FuncTWO, $VarONE, $VarTWO);

Replace all those my()s with our()s.  The variables @ISA, @EXPORT and 
@EXPORT_OK must be package variables.

-- 
Rick Delaney
rick.delaney@rogers.com


------------------------------

Date: Fri, 16 May 2003 19:49:58 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: Exporter not doing what I expect
Message-Id: <3ec54007.298215103@news.erols.com>

"Michael P. Broida" <michael.p.broida@boeing.com> wrote:

: Well, I thought I had fixed it, but it's still not correct.  Need some more help.
: 
: I now have this:
: 
: In XYZ.pm:
: 	package XYZ;
: 	use strict;
: 	use warnings;
: 	require Exporter;
: 	my @ISA = qw(Exporter);
: 	my @EXPORT = qw();
: 	use vars qw($VarONE, $VarTWO);  # Next line didn't work without this one

Is there a reason to prefer "use vars" over "our"?

: 	my @EXPORT_OK = qw(FuncONE, FuncTWO, $VarONE, $VarTWO);
                           ^      ^        ^        ^
                           ^      ^        ^        ^
You're not getting warnings about "Possible attempt to separate words
with commas"?  That mistake is pervasive in this sample code.

Exporter is not the problem.  It's doing nothing since it cannot see
your lexical @ISA, @EXPORT and @EXPORT_OK.  They need to be package
variables.  s/my/our/

: I get NO complaints about the use of FuncTHREE even though it is
: not exported or imported.

: I get errors that the uses of $VarONE and $VarTWO need explicit
: package names specified.

There's something else happening that we haven't seen.

Do calls to FuncONE(), etc. work when the "use XYZ;" line is removed?
It sounds an awful lot like a different module is putting subs with
the same names into your main:: namespace.

I'd dump the symbol table for a look at what subs are in whose
namespaces.



------------------------------

Date: Fri, 16 May 2003 20:08:31 GMT
From: "Michael P. Broida" <michael.p.broida@boeing.com>
Subject: Re: Exporter not doing what I expect
Message-Id: <3EC5453F.D3838927@boeing.com>

Gunnar Hjalmarsson wrote:
> 
> Michael P. Broida wrote:
> >       From reading (and re-reading and re-reading) the Camel book, it
> >       seems that this SHOULD limit the "users" of XYZ to being able to
> >       access ONLY those functions/variables that are in the EXPORT list.
> 
> Note that the purpose of exporting things is not to _limit_ access to
> anything that is not exported. Exporting the name of a function or
> variable may make that function or variable available in some other
> package/namespace without a need to qualify them.

	OK.  I guess I'm not expressing myself well.  I think what
	I'm looking for is not so much "access" but just being able
	to use the item without adding the "packagename::" on the
	front.  That seems to match what you are saying the Export
	/import stuff should provide.

	But I seem to be able to use SOME items without the qualifier
	even if they are are NOT exported.  That's ONE of the things
	that is bothering me.

	The other is that the "$variable" items that I export/import
	are NOT available without qualifying them; I get errors that
	say I must provide a packagename at the point of reference.

	It's just not being consistent.  <grumble, pout, whine>
	:)

	Please see my third post on this thread (from about
	1:41pm CentralUSTime, if it makes it to your news
	server) for some gory details.

		Thanks for the response!
			Mike


------------------------------

Date: Fri, 16 May 2003 20:22:29 GMT
From: "Michael P. Broida" <michael.p.broida@boeing.com>
Subject: Re: Exporter not doing what I expect
Message-Id: <3EC54885.281E1C40@boeing.com>

Rick Delaney wrote:
> 
> "Michael P. Broida" <michael.p.broida@boeing.com> writes:
> 
> > Hi again!  (Replying to myself, but slightly different problem.)
> >
> > Well, I thought I had fixed it, but it's still not correct.  Need some more help.
> >
> > I now have this:
> >
> > In XYZ.pm:
> >       package XYZ;
> >       use strict;
> >       use warnings;
> >       require Exporter;
> >       my @ISA = qw(Exporter);
> >       my @EXPORT = qw();
> >       use vars qw($VarONE, $VarTWO);  # Next line didn't work without this one
> >       my @EXPORT_OK = qw(FuncONE, FuncTWO, $VarONE, $VarTWO);
> 
> Replace all those my()s with our()s.  The variables @ISA, @EXPORT and
> @EXPORT_OK must be package variables.

	Yep!  That was exactly the problem.  I made the
	changes you suggested and it works great!  I
	even get errors when trying to use something
	that's not exported (unless I explicitly say
	"packagename::").

	Oh, also: my sample code has typos.  My real
	code does NOT have commas in the qw() blocks.  :)

		Thanks!
			Mike


------------------------------

Date: Fri, 16 May 2003 20:20:33 GMT
From: "Michael P. Broida" <michael.p.broida@boeing.com>
Subject: Re: Exporter not doing what I expect
Message-Id: <3EC54811.18633450@boeing.com>

Jay Tilton wrote:
> 
> "Michael P. Broida" <michael.p.broida@boeing.com> wrote:
> 
> : Well, I thought I had fixed it, but it's still not correct.  Need some more help.
> :
> : I now have this:
> :
> : In XYZ.pm:
> :       package XYZ;
> :       use strict;
> :       use warnings;
> :       require Exporter;
> :       my @ISA = qw(Exporter);
> :       my @EXPORT = qw();
> :       use vars qw($VarONE, $VarTWO);  # Next line didn't work without this one
> 
> Is there a reason to prefer "use vars" over "our"?

	Nope.  I did this before I heard of "our".  And it wouldn't
	let me add the variables to EXPORT_OK or EXPORT until I
	added the "use vars" line first.  If "our" is better (and
	another poster indicated so), then I'll try changing that.
	---->Nope, that alone didn't fix it, but read on.

> :       my @EXPORT_OK = qw(FuncONE, FuncTWO, $VarONE, $VarTWO);
>                            ^      ^        ^        ^
>                            ^      ^        ^        ^
> You're not getting warnings about "Possible attempt to separate words
> with commas"?  That mistake is pervasive in this sample code.

	Oops.  No, my code does NOT have those commas.  It did at
	one point, but I got the error you mention and corrected it.
	Then I typoed in my samples.  So, ignore those commas.  :)

> Exporter is not the problem.  It's doing nothing since it cannot see
> your lexical @ISA, @EXPORT and @EXPORT_OK.  They need to be package
> variables.  s/my/our/

	OK, that makes sense.  I'll swap that and see what happens.
	The Camel book doesn't use "my" or "our", but I found I had
	to have SOMETHING there.

	YEP, that worked a treat!!  Thanks!  Now I know what "our"
	is for.  :)

> : I get NO complaints about the use of FuncTHREE even though it is
> : not exported or imported.
> 
> : I get errors that the uses of $VarONE and $VarTWO need explicit
> : package names specified.
> 
> There's something else happening that we haven't seen.
> 
> Do calls to FuncONE(), etc. work when the "use XYZ;" line is removed?
> It sounds an awful lot like a different module is putting subs with
> the same names into your main:: namespace.

	I can't reproduce the first case above, and the change from
	"my" to "our" has removed the second case.  I could have
	been confusing myself with testcase on top of testcase.
	But there are no other modules with these function names
	(I made them VERY unique to my purposes).

> I'd dump the symbol table for a look at what subs are in whose
> namespaces.

	Seems that isn't needed in this case.  The "our" change
	did the trick and I'm all set!

	Thanks for the answers!  Hope I can remember what I've
	learned about this!  <grin>

			Mike


------------------------------

Date: Fri, 16 May 2003 23:11:15 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Exporter not doing what I expect
Message-Id: <ba3k5q$obu4h$1@ID-184292.news.dfncis.de>

Michael P. Broida wrote:
> Jay Tilton wrote:
>> "Michael P. Broida" <michael.p.broida@boeing.com> wrote:
>> 
>> :       use vars qw($VarONE, $VarTWO);  # Next line didn't work
>> without this one
>> 
>> Is there a reason to prefer "use vars" over "our"?
> 
> Nope.  I did this before I heard of "our".  And it wouldn't let me
> add the variables to EXPORT_OK or EXPORT until I added the "use
> vars" line first.  If "our" is better (and another poster indicated
> so), then I'll try changing that.

"our" is _shorter_ than "use vars"...

If you want your program to be able to be run with Perl versions older
than 5.6.0, you _must_ use "use vars". I always use "use vars" as soon
as portability is an issue.

/ Gunnar

-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl



------------------------------

Date: 16 May 2003 14:22:04 -0700
From: google@sleepdep.net (Jason McManus)
Subject: fchown and fchmod
Message-Id: <50481f2e.0305161322.4f91755d@posting.google.com>

Greetings all,

I am really disturbed by the lack of existence of fchmod and fchown in
perl.  I have scoured the entire web, usenet, and various offline
resources, and I am fairly convinced that no perl programmers actually
practice secure programming.  The problem is thus: with this segment
of code:

my @stats = stat("/tmp/test.txt");
if (($stats[3] == 1) && (S_ISREG($stats[2]))) {
    chown($uid,$gid,"/tmp/test.txt");
}

a race condition exists, where if the user-owner deletes and creates a
hardlink from test.txt to, say, /etc/passwd, in between the time the
stat() function and the chown() function is run (which is not as
outlandish as one might think, think renice, etc.), this will
completely subvert local system integrity.  I've been working on a
program to change user and group ownership of several hundred user's
files on a shared server to ensure the files affect the user's quota,
when I discovered the lack of these two calls.  The proper way to do
this securely is thus:

open(F,"/tmp/test.txt") or die "Bjork! $!\n";
my @stats = stat(F);
if (($stats[3] == 1) && (S_ISREG($stats[2]))) {
    fchown($uid,$gid,F);
}
close(F);

The fact that stat() can accept either a filename or a filehandle
shows that this is very possible, and that stat() automagically makes
the determination whether or not it has been passed a filename or
handle shows that this would be very easy to implement.

There is a workaround, of course; anything is possible in development.
 However, to make the workaround portable across platforms requires
several dozen lines of code for a simple call that should be
implemented either transparently in chown() or separately, and throw
an exception if the local system does not support the call.  To see
roughly how to do this, search this group from Jan 12, 2000, a fact
that in itself is very illustrative of the lack of security
consideration in software development.

Technically, I see that fchown(2) is not POSIXly correct, which is
very likely the thinking behind excluding this function from the
standard library, but from a security standpoint, this omission is
very disturbing indeed.

Cheers,
Jason McManus
<google-nospam@SPAM.sleepdep.net>


------------------------------

Date: Fri, 16 May 2003 22:04:08 GMT
From: Rick Delaney <rick.delaney@rogers.com>
Subject: Re: fchown and fchmod
Message-Id: <m34r3umtuw.fsf@biff.bort.ca>

google@sleepdep.net (Jason McManus) writes:

> Greetings all,
> 
> I am really disturbed by the lack of existence of fchmod and fchown in
> perl.

perldoc -f syscall

-- 
Rick Delaney
rick.delaney@rogers.com


------------------------------

Date: Fri, 16 May 2003 18:35:44 +0000 (UTC)
From: veky@cromath.math.hr (Veky)
Subject: Re: find and replace script... please help.
Message-Id: <ba3b20$5pm$1@bagan.srce.hr>

Dok je Veky citao comp.lang.perl.misc, pod PIDom 26468 (290038 off, 9 to go...),
primijetio je kreaturu zvanu Brad Murray <bjm-nntp@vsca.ca>,
ispod cijih su prstiju izasle (izmedu ostalih) sljedece rijeci:

|Helgi Briem <helgi@decode.is> wrote:
|HB> Use a hash to store the replacements, i.e.+
|HB> my ($old,$new) = split /:/,$line;
|HB> %replacement_for{$old} = $new;
|
|%repl = ( %repl,split(/:/,$line));

You meant %repl=(%repl,reverse split/:/,line) , didn't you:-? :-)

-- 
\#{%	Sad gradi svoj grad iz snova... znaj da mozes i znaj da znas...


------------------------------

Date: 16 May 2003 13:46:29 -0700
From: google@billjonline.com (bill j)
Subject: how do i hide a password?
Message-Id: <60c9e8e2.0305161246.79ebaf87@posting.google.com>

I am new to the Perl DBI and am wanting some suggestions on how I
might handle this:

my site is hosted remotely and, frankly, I don't want the people who
host it to have access to my DB password which is visible if they were
to look at my Perl script.  What is the best way to keep this secure
and still be able to use it to login with my Perl script.  Is there a
way to encrypt/decrypt it so that it is only visible to the script as
it is running?  Any input would be helpful!

Thanks!

Bill


------------------------------

Date: 16 May 2003 12:30:57 -0700
From: xah@xahlee.org (Xah Lee)
Subject: oddity per sort internal
Message-Id: <7fe97cc4.0305161130.e86e16c@posting.google.com>

can anyone give a good explanation on why the following code (attached
below) doesn't reach the error printing statement?

i think the question comes down to the precise specification of when
or how mySort is called in
  sort {mySort($a,$b)} @array
I suppose it's not predictive.

what's a better way to write what i wanted in the following code?

thanks.

 Xah
 xah@xahlee.org
 http://xahlee.org/PageTwo_dir/more.html



#!/usr/bin/perl
use strict;
use Data::Dumper;

# problem: sort a given list @aa, by a given ordered superset @os.

my @aa = (1,2,55,3,4);
my @os = (7, 8, 6, 2, 5, 1, 9, 0, 3, 4);

my @result;

@result = sort {mySort($a,$b)} @aa;

sub mySort($$) {
my $e1=$_[0];
my $e2=$_[1];

for (@os) {if ($e1 == $_) {return -1}; if ($e2 == $_) {return 1}}
print "error: $e1 or $e2 is not in the superset\n";
}

print Dumper \@result;


------------------------------

Date: Fri, 16 May 2003 12:54:11 -0700
From: Steven Kuo <skuo@mtwhitney.nsc.com>
Subject: Re: oddity per sort internal
Message-Id: <Pine.GSO.4.21.0305161251330.2128-100000@mtwhitney.nsc.com>

On 16 May 2003, Xah Lee wrote:

> can anyone give a good explanation on why the following code (attached
> below) doesn't reach the error printing statement?


Select any two numbers from @aa; can you find a combination for which
either 'return 1' or 'return -1' is not executed (in sub mySort)?


> i think the question comes down to the precise specification of when
> or how mySort is called in
>   sort {mySort($a,$b)} @array
> I suppose it's not predictive.
> 
> what's a better way to write what i wanted in the following code?
> 
> thanks.
> 
>  Xah


I don't understand what you wanted to write...


> 
> #!/usr/bin/perl
> use strict;
> use Data::Dumper;
> 
> # problem: sort a given list @aa, by a given ordered superset @os.
> 
> my @aa = (1,2,55,3,4);
> my @os = (7, 8, 6, 2, 5, 1, 9, 0, 3, 4);
> 
> my @result;
> 
> @result = sort {mySort($a,$b)} @aa;
> 
> sub mySort($$) {
> my $e1=$_[0];
> my $e2=$_[1];
> 
> for (@os) {if ($e1 == $_) {return -1}; if ($e2 == $_) {return 1}}
> print "error: $e1 or $e2 is not in the superset\n";
> }
> 
> print Dumper \@result;
> 

-- 
Hope this helps,
Steven



------------------------------

Date: Fri, 16 May 2003 20:38:19 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: oddity per sort internal
Message-Id: <3ec54227.298758767@news.erols.com>

xah@xahlee.org (Xah Lee) wrote:

: can anyone give a good explanation on why the following code (attached
: below) doesn't reach the error printing statement?

[code shifted up from below signature]

: #!/usr/bin/perl
: use strict;
: use Data::Dumper;
: # problem: sort a given list @aa, by a given ordered superset @os.
: my @aa = (1,2,55,3,4);
: my @os = (7, 8, 6, 2, 5, 1, 9, 0, 3, 4);
: my @result;
: @result = sort {mySort($a,$b)} @aa;
: sub mySort($$) {
: my $e1=$_[0];
: my $e2=$_[1];
: for (@os) {if ($e1 == $_) {return -1}; if ($e2 == $_) {return 1}}
: print "error: $e1 or $e2 is not in the superset\n";
: }
: print Dumper \@result;

There's only one element in @aa that is not in @os.  Either $a or $b
is guaranteed to match.

: what's a better way to write what i wanted

    my %order;
    @order{@os} = 0 .. $#os;
    if( my @extras = grep !exists $order{$_}, @aa ) {
        die "not in the superset: @extras";
    }
    my @result = sort { $order{$a} <=> $order{$b} } @aa;
    print Dumper \@result;



------------------------------

Date: 16 May 2003 21:28:27 GMT
From: Tina Mueller <usenet@tinita.de>
Subject: Re: oddity per sort internal
Message-Id: <ba3l5r$p9co1$1@ID-24002.news.dfncis.de>

Xah Lee <xah@xahlee.org> wrote:
> @result = sort {mySort($a,$b)} @aa;

> sub mySort($$) {

you can just say:
@result = sort mySort @aa;

hth, tina
-- 
http://www.tinita.de/     \  enter__| |__the___ _ _ ___
http://Movies.tinita.de/   \     / _` / _ \/ _ \ '_(_-< of
http://www.perlquotes.de/   \    \ _,_\ __/\ __/_| /__/ perception
http://www.tinita.de/peace/link.html - Spread Peace


------------------------------

Date: Fri, 16 May 2003 13:17:51 -0500
From: Chris Olive <nospam@raytheon.com>
Subject: Re: one liner in command line
Message-Id: <dX9xa.3308$c6.3298@bos-service2.ext.raytheon.com>

Graham Drabble wrote:
> On 04 May 2003 Michael Eric Battle <you.gotta.be@kidding.com> wrote 
> in news:3EB46B2F.6780FC05@kidding.com:
> 
> 
>>Graham Drabble wrote:
>>
>>>I think this is a Windows/Unix thing.
>>
>>Maybe.  
>>Maybe you're better off with the single quotes.
>>
>>The double quotes interpolate (at the shell level)
>>for shell escape characters like \ and $ so you have
>>to do:
> 
> 
> I don't think that the windows command line is that clever. I found 
> this in the ActiveState docs
> 
> ====
> Why doesn't 'perl -e' work?
> It does - it's just that some command shells (for example 
> COMMAND.COM, CMD.EXE and 4DOS) don't accept single quotes wrapped 
> around command arguments.
> 
> The safest way to do perl one-liners is to wrap the parameters within 
> "" (double-quotes) the use q() and qq() inside the parameters. q() 
> and qq() with put whatever is inside them between single-quotes or 
> double-quotes, respectively.
> For example:
> 
>     perl -e "use LWP::Simple; while(@c = head <>) { $c = join qq(\n
> \t), @c; print qq(Header info:\n\t$c\n); }"
> 
> (this was all one line)
> Run this from the command line and type in the URL to your favorite 
> website, like http://www.perl.com/...
> 
> The perlwin32 and perlrun POD pages have more information on using 
> the command line.
> ====
> 

Or upgrade Windows by installing Cygwin and run Perl in a real 
environment/command shell that isn't lobotamaized.  (As nice as ASPN 
itself is for Windows).

Chris
-----
Chris Olive
Systems Consultant
Raytheon Technical Services Corporation
Indianapolis, IN

email: olivec(AT)indy(DOT)raytheon(DOT)com



------------------------------

Date: 16 May 2003 13:31:22 -0700
From: botfood@yahoo.com (dan baker)
Subject: possible bug in m// ?
Message-Id: <13685ef8.0305161231.2c4bae1d@posting.google.com>

I am attempting to catch illegal formats for zip codes, and think I
have a bug in the "exact number of times" part of regex. the snippet
is:

	unless ( ($MemberZip =~ m/\d{5}/) or ($MemberZip =~ m/\d{5}\-\d{4}/))
{
	$FormErrorMsg .= " \n<li> Zip must be either 5 digit, or 5+4 format."
}

What is happening is that values with more than 5 digits are passing
right thru without getting caught. Am I doing something wrong with
regex or is this a bug? Running perl 5.00503 from activestate on
windows98.


D


------------------------------

Date: Fri, 16 May 2003 22:39:15 +0200
From: Matija Papec <mpapec@yahoo.com>
Subject: Re: possible bug in m// ?
Message-Id: <bqiacvstkl63q0aedf10a275dg9dcohr7n@4ax.com>

X-Ftn-To: dan baker 

botfood@yahoo.com (dan baker) wrote:
>	unless ( ($MemberZip =~ m/\d{5}/) or ($MemberZip =~ m/\d{5}\-\d{4}/))
>{
>	$FormErrorMsg .= " \n<li> Zip must be either 5 digit, or 5+4 format."
>}
>
>What is happening is that values with more than 5 digits are passing
>right thru without getting caught. Am I doing something wrong with
>regex or is this a bug?

You have to set anchors in regex, eg.

$MemberZip =~ /^\d{5}$/

(match five digits from begining to end of $MemberZip)



-- 
Matija


------------------------------

Date: Fri, 16 May 2003 21:40:07 GMT
From: Andras Malatinszky <nobody@dev.null>
Subject: Re: possible bug in m// ?
Message-Id: <3EC55A39.40209@dev.null>



dan baker wrote:

> I am attempting to catch illegal formats for zip codes, and think I
> have a bug in the "exact number of times" part of regex. 

If there really were a bug in such a not-at-all-obscure part of Perl 
don't you think it's likely that other people would already have notice, 
reported and fixed that.

>the snippet
> is:
> 
> 	unless ( ($MemberZip =~ m/\d{5}/) or ($MemberZip =~ m/\d{5}\-\d{4}/))
> {
> 	$FormErrorMsg .= " \n<li> Zip must be either 5 digit, or 5+4 format."
> }
> 
> What is happening is that values with more than 5 digits are passing
> right thru without getting caught. 

Note that by saying /\d{5}/ you are really just trying to see if there 
is a sequence of five consecutive digits in the string. So if your user 
sets $MemberZip='9876543', your regex will match the '98765' part of 
that and the program will skip the error message. What you want, in fact 
is /^\d{5}$/, which means "five digits and nothing else."

You might want to strip out whitespace first though, in case someon 
enters '90210 ' which is not really wrong. Also, is it possible some of 
your users live in a place where zip codes look more like "3D5 H41" or 
"1036"?

>Am I doing something wrong with
> regex or is this a bug? Running perl 5.00503 from activestate on
> windows98.


Did you know that 5.8 is already available from ActiveState.



------------------------------

Date: 16 May 2003 13:35:08 -0700
From: dpds.nospam@dpds.net (Deltran Municipa)
Subject: Unicode UTF8/UTF16 Regexp Problem
Message-Id: <fa11a06d.0305161235.17bdd3c5@posting.google.com>

I'm using Unicode::String and Unicode::Lite
I've tried this on a Win32 Machine and Linux, both exhibiting similar
problems, using perl 5.8.0

I have a string :

'@"o @_a A crazy test ö'

'@"o' and '@_a' are ascii codes from a legacy system used to represent
Unicode characters.  So the purpose of my program is to convert these
to actual Unicode values.

I first convert the string to UTF8 :

$_ = convert('latin1','utf8',$_);

then I pass it through this, printing out after each step, just to
debug :

if (/\@/ || /\$/) {
	s|\@_a|\x{0101}|g;
	print "$_";
	s|\@"o|\x{00F6}|g;
	print "$_";
}

I then convert to utf16.
$_ = convert('utf8','utf16',$_);

Doing this, '@"o' gets converted to 'ö' and @_a gets converted to
'&#257;'.  That last character is a lower case 'a' with a bar over it,
in case that doesn't appear properly.  This works exactly how I want
it to work.  However, when I use a different test string :

'@"o A crazy test ö'
(the difference being that '@_a' is not in this string)

I get the following error :

'Bad 2nd, 3rd or 4th byte of utf8 encoded char'

I am guessing that the 'ö' is now being interpreted as one part of a
utf8 character.  It gets discarded completely when going to utf16.

You may be wondering why I initially go from latin1 to utf8.  I'm not
100% sure of my reasons, but it seems this is necessary in order to
retain the initial extended character 'ö' (at the end of the string). 
If I leave out this conversion, I then lose this character as well.

I tried going from latin1 to utf16 right at the start, but then the
regular expressions do not work, as I expected them not to.  I'm
thinking that perhaps getting a unicode regexp to work may be what I
want.

Perhaps there's a better way to do this?

Thanks,
  Deltran


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc.  For subscription or unsubscription requests, send
the single line:

	subscribe perl-users
or:
	unsubscribe perl-users

to almanac@ruby.oce.orst.edu.  

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.

For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V10 Issue 4996
***************************************


home help back first fref pref prev next nref lref last post