[16883] in Perl-Users-Digest
Perl-Users Digest, Issue: 4295 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Sep 12 06:10:23 2000
Date: Tue, 12 Sep 2000 03:10:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <968753411-v9-i4295@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 12 Sep 2000 Volume: 9 Number: 4295
Today's topics:
Problem with @INC <engelbrecht@dachs.de>
Re: Problem with @INC <peter@wastholm.com>
Re: Problem with @INC <Peter.Dintelmann@dresdner-bank.com>
Re: Problem with @INC (Rafael Garcia-Suarez)
Re: Problem with join function (and split function) <g.soper@soundhouse.co.uk>
Re: Problem with join function (and split function) <elephant@squirrelgroup.com>
Resolving IP's Q: Does this IP actually exist? <ralawrence@my-deja.com>
Re: simple question <nickco3@yahoo.co.uk>
Re: Some question in using Perl Cookie from a PERL begi <2kman@lovecat.com>
Re: Some question in using Perl Cookie from a PERL begi <elephant@squirrelgroup.com>
Tim Falzone <hoffboy@excite.com>
Re: Unix ps and perl question <nickco3@yahoo.co.uk>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 12 Sep 2000 11:37:06 +0200
From: "Jens Engelbrecht" <engelbrecht@dachs.de>
Subject: Problem with @INC
Message-Id: <8pktg4$3ai$1@oak.fernuni-hagen.de>
Hello,
I am trying to include my written module "Debug.pm" into my perl script. The
module is in the directory "/cgi-bin/modules".
The directory and the module is set to "755".
The code of my perl script is the following:
#!/usr/bin/perl -w
unshift (@INC, "$ENV{'HOME'}/cgi-bin/modules");
#module
use Debug;
#do something...
I get the following error message:
Can\'t locate Debug.pm in @INC (@INC contains:
/usr/lib/perl5/5.00502/i586-linux /usr/lib/perl5/5.00502
/usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 .)
What have I missed?
Thanks for your help.
Jens
------------------------------
Date: Tue, 12 Sep 2000 09:58:22 GMT
From: Peter Wastholm <peter@wastholm.com>
Subject: Re: Problem with @INC
Message-Id: <39BDFDB3.F1BC7A82@wastholm.com>
Jens Engelbrecht wrote:
>
> The code of my perl script is the following:
>
> #!/usr/bin/perl -w
> unshift (@INC, "$ENV{'HOME'}/cgi-bin/modules");
> #module
> use Debug;
> #do something...
>
> I get the following error message:
>
> Can\'t locate Debug.pm in @INC (@INC contains:
The @INC manipulation must take place before use Debug:
BEGIN {unshift @INC, "$ENV{'HOME'}/cgi-bin/modules";}
/Peter
------------------------------------------------------------------------
Peter Wastholm A little inaccuracy sometimes saves a ton of
peter@wastholm.com explanation. H. H. Munro
"Aphorisms Galore!" -- Feed Your Wit http://www.aphorismsgalore.com/
------------------------------
Date: Tue, 12 Sep 2000 11:52:32 +0200
From: "Dr. Peter Dintelmann" <Peter.Dintelmann@dresdner-bank.com>
Subject: Re: Problem with @INC
Message-Id: <8pkucd$sko2@intranews.bank.dresdner.net>
Hi,
Jens Engelbrecht schrieb in Nachricht
<8pktg4$3ai$1@oak.fernuni-hagen.de>...
>#!/usr/bin/perl -w
>unshift (@INC, "$ENV{'HOME'}/cgi-bin/modules");
>#module
>use Debug;
>#do something...
>
>I get the following error message:
>
>Can\'t locate Debug.pm in @INC (@INC contains:
>/usr/lib/perl5/5.00502/i586-linux /usr/lib/perl5/5.00502
>/usr/lib/perl5/site_perl/5.005/i586-linux
/usr/lib/perl5/site_perl/5.005 .)
>
>What have I missed?
'use' is done at compile time but your 'unshift'
is executed at run time. So execute your @INC
modification at compile time before looking for
'Debug'.
BEGIN{ unshift @INC, "$ENV{HOME}/cgi-bin/modules" }
use Debug;
Regards,
Peter Dintelmann
------------------------------
Date: Tue, 12 Sep 2000 09:57:43 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: Problem with @INC
Message-Id: <slrn8rrvsl.o5.rgarciasuarez@rafael.kazibao.net>
Jens Engelbrecht wrote in comp.lang.perl.misc:
>Hello,
>I am trying to include my written module "Debug.pm" into my perl script. The
>module is in the directory "/cgi-bin/modules".
>The directory and the module is set to "755".
>The code of my perl script is the following:
>
>#!/usr/bin/perl -w
>unshift (@INC, "$ENV{'HOME'}/cgi-bin/modules");
>#module
>use Debug;
>#do something...
'use' is compile-time, 'unshift' is runtime.
Try :
BEGIN { unshift (@INC, "$ENV{'HOME'}/cgi-bin/modules"); }
or better,
use lib "$ENV{'HOME'}/cgi-bin/modules";
(Note also that the HOME environnement variable will be the one of your
web server, not yours.)
--
Rafael Garcia-Suarez | http://rgarciasuarez.free.fr/
------------------------------
Date: Tue, 12 Sep 2000 09:00:02 +0100
From: Geoff Soper <g.soper@soundhouse.co.uk>
Subject: Re: Problem with join function (and split function)
Message-Id: <49fcc5e1b0g.soper@soundhouse.co.uk>
In article <MPG.142828cbae4b8ac2989783@localhost>, jason
<elephant@squirrelgroup.com> wrote:
> Geoff Soper <g.soper@soundhouse.co.uk> wrote ..
> >In a script I have tried to take an array and join its elements into
> >one string delimited by colons. This doesn't seem to be working. The
> >line in question is line 95 and the script is
> >http://www.soundhouse.co.uk/cgi-bin/2.cgi which is available for
> >inspection at http://www.soundhouse.co.uk/geoff as is the database
> >file. Through debugging I have established that it is an array before
> >and after using join on it.
> >
> in future please post a short code example showing the problem you're
> having .. people here appreciate not having to go to your web site to
> look at the code
I'm always hesitant about posting large pieces of code but I will post
snippets in the future
> the problem in your code starts with this line
> $form_data{$_} = [param($_)] for param();
> which is storing an array REFERENCE into the %form_data hash .. it's not
> storing an array .. therefore when you do the join later on the second
> argument to the join is actually an array reference - where it should be
> an array (or more accurately a list)
OK I'll take your word for it, that doesn't mean a huge amount to me! That
piece of code was actually suggested to me by somebody else:
On 10 Sep in comp.lang.perl.misc, Randal L. Schwartz
<merlyn@stonehenge.com> wrote:
> If you have a "select multiple", then that code returns the *first*
> selected item, not all of them. A more general capture will be to make
> a multiple-hits-safe structure, as:
> use CGI qw(param);
> my %data;
> $data{$_} = [param($_)] for param();
> Now $data{"bigfield"}[0] is the first (possibly only) value for
> "bigfield".
***** end quote ******
This lead me to think that $data{"bigfield"} would therefore be an array,
you're saying that it's a reference?
> an array reference is only one list element .. so there's nothing to
> 'join' with .. and you get back the array reference
> you need to either store the array itself in the %form_data hash .. or
> dereference the arrayref in the 'join' call like this
I think I really need to fix this at the source and store the array in the
%form_data hash instead of trying to fix it later in the code.
> join ":", @{$form_data{$form_field}};
> NB: this confusion between an array and an arrayref is probably causing
> problems elsewhere in your code
Great :-)
Thanks for your time and help
--
Geoff Soper
g.soper@soundhouse.co.uk
Take a look at the Soundhouse page http://www.soundhouse.co.uk/
------------------------------
Date: Tue, 12 Sep 2000 19:13:05 +1100
From: jason <elephant@squirrelgroup.com>
Subject: Re: Problem with join function (and split function)
Message-Id: <MPG.142882885b8c7098978a@localhost>
Geoff Soper <g.soper@soundhouse.co.uk> wrote ..
>In article <MPG.142828cbae4b8ac2989783@localhost>, jason
><elephant@squirrelgroup.com> wrote:
-
>> you need to either store the array itself in the %form_data hash .. or
>> dereference the arrayref in the 'join' call like this
>
>I think I really need to fix this at the source and store the array in the
>%form_data hash instead of trying to fix it later in the code.
I don't know where my head was .. (as others will almost certainly pull
me up on) you cannot store the entire array in the one element .. you
have to store the array reference (as Randal showed)
which means that you have to use the following syntax later on to get at
the array
>> join ":", @{$form_data{$form_field}};
>
>> NB: this confusion between an array and an arrayref is probably causing
>> problems elsewhere in your code
>
>Great :-)
take some time out and read about references in the perlref section of
the documentation .. type the following at a command prompt
perldoc perlref
what you're dealing with here is explained in point (2) - a reference to
an anonymous array .. it's worthwhile learning it - because there's a
lot in Perl that you cannot do without references
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Tue, 12 Sep 2000 09:11:13 GMT
From: Richard Lawrence <ralawrence@my-deja.com>
Subject: Resolving IP's Q: Does this IP actually exist?
Message-Id: <8pkrv8$s89$1@nnrp1.deja.com>
Hi,
Quick question as I've searched the deja archive and only come up with
questions about gethostbyaddr (which isn't what I'm looking for).
I have a large number of IP and domains and also their port numbers and
I'd like to find out which are valid and which are not.
The idea is to have a function that is called check_site with two
arguments, site and port. If the site can be resolved in less than 5
seconds and has something running on that port then I'd like it to
return 1 otherwise 0.
I tried using IO::Socket to make a connection however setting the
Timeout value to 5 still causes the code to hang for up to two minutes
trying to connect a site that either doesn't exist or is very slow at
being looked up.
So I wrapped an alarm 5 and die around the code but that still doesn't
work. I still get long waits on dodgy sites.
Can anyone advise me if it is possible to find out whether a site
exists quickly and easily within a certain amount of alloted time? If
anyones solution doesn't require connecting to a port then thats fine,
because it means I can test first and then connect to the port
afterwards.
Since there is over 1000 of these IP's and a good proportion of them
will be dodgy you can understand the reasoning behind the 5 second
timeout (rather than 2 minutes) - although i can appreciate that with a
short timeout value some sites will be reported as not available when
really they are.
Can anyone advise?
Thanks
Rich
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 12 Sep 2000 10:12:34 +0100
From: Nick Condon <nickco3@yahoo.co.uk>
Subject: Re: simple question
Message-Id: <39BDF382.D06DDF5A@yahoo.co.uk>
interlocator@my-deja.com wrote:
> How can I pass a value from one script like username to another script
> to do more stuff with it?
Passing data from one app to another is what Perl really excels at, so
there are many answers.
> Or at least can you tell me what this is called so I can look it up
> myself. This has been the biggest problem for me, knowing what some
> process is called to be able to learn it.
Are these scripts running concurrently or consecutively? It makes a big
difference.
A list off the top of my head of passing data from script A to script B:
- Start script A and it calls script B with commandline arguments.
- Script A sets environment variables, which script B reads.
- Script A outputs the data to a file, which script B reads.
- Script B calls `script A` in backticks; script A writes the data to
STDOUT.
- Script A calls open("| script B") and writes the data to this new
filehandle.
- Script B call open ("script A |") and script A writes to STDOUT.
- Script A is a module and script B imports it.
- Script A sets up a pipe(), then fork()s. (Err .. we now have 2 script
As, but where did script B go?)
- Create a named pipe (man mkfifo)
- Your system might support Sys V shared memory (see IPC::Shareable)
- Script B creates a TCP socket and listens; script A connects to the
socket and writes the data to it.
- Script A creates a TCP socket and listens; script B connects to the
socket and reads data from it.
Perhaps it would be better if you gave us an example?
---
Nick
------------------------------
Date: Tue, 12 Sep 2000 12:05:39 +0800
From: Kit <2kman@lovecat.com>
Subject: Re: Some question in using Perl Cookie from a PERL beginner
Message-Id: <39BDAB93.C952FBE3@lovecat.com>
I appreciated for getting Jason help
jason wrote:
> Kit <2kman@lovecat.com> wrote ..
> >Dear all, I am beginner of using Perl and have some question when using
> >cookie. Hope you can help me to solve it.
> >
> >Firstly, I pass value "apple" to aa.cgi through index.html. When going
> >to bb.cgi, it would load the value (i.e. 'apple') in cookie 'aaa' and do
> >
> >something. When going to cc.cgi, the value in cookie 'aaa' ( ie 'apple')
> >
> >would be reset. The coding is described as following:-
> >
> ># In aa.cgi >>
> >#!/usr/bin/perl
> >$in1=new CGI;
> >$cookie=$in1->cookie(-name=>'aaa', -value=>"$var1");
> >print $in1->header(-cookie=>$cookie);
> >
> >
> ># In bb.cgi >>
> >#!/usr/bin/perl
> >$get1=new CGI;
> >$var1=$get1->cookie(-name=>"aaa");
> >
> ># In cc.cgi >>
> >#!/usr/bin/perl
> >$out=new CGI;
> >$cookie=$out->cookie(-name=>'aaa', -value=>"");
> >print $out->header(-cookie=>$cookie);
> >
> >1. Would it either create new cookie in browser or add the value into
> >current portal cookie?
>
> as was recently discovered in this newsgroup .. this depends on which
> version of CGI::Cookie you're using
>
> another part of cookies that you might not be aware of (other than
> 'name' and 'value') is 'path' .. this tells the browser when to return
> the cookie to the server
>
> if you don't provide a path value yourself then the CGI::Cookie module
> will create one for you .. the default value for this path has changed a
> few times and does not always match the documentation
>
> so .. best bet is to include the path explicitly yourself .. ie.
>
> $cookie = $out->cookie( -name => 'aaa', -value => "", -path = '/');
>
> this will set the path of that cookie to '/' which means that the
> browser will send back that cookie with ALL scripts executed on the
> server
>
> you could also set it to $ENV{SCRIPT_NAME} in which case the browser
> would only send it back for THAT script .. ie. for the xx.cgi program
> that the cookie was set in
>
> and that's the answer to your question
>
> a new cookie will be created if the path setting prevents the browser
> from sending back the cookie that another script set (this would be the
> $ENV{SCRIPT_NAME} example above) .. but the same cookie will be updated
> if the path setting allows the browser to send back the same cookie
> (this would be the '/' example above)
>
I use ActivePearl currently.
Either setting fixed path or using original path (i.e. not setting fixed
path), which one would be more secure and better?
If I expect not to set the path, would it use the default path of browser?
Would cookie store at harddisk physically or only store in memory logically
before reset the cookie value?
>
> >2. Since I don't set the expiry date, I assume the cookie would be
> >deleted once closing browser. If someone has stolen the cookies before
> >closing browser, would the guy can copy the cookie file to her/his PC
> >and then directly type the path of bb.cgi with getting the value 'apple'
> >without calling aa.cgi or index.html?
>
> yes - you're correct - when the browser closes the cookie will be
> removed from memory because you have not set an expiry date
>
> I don't know what you mean by 'stolen' ? .. people don't steal cookies -
> you send them to them
>
> I think the question that you're looking for is "don't trust cookies for
> anything more than convenience, they are not secure"
>
I mean if the cookie stores in harddisk during run-time, how to prevent the
guy getting the cookie and then copy the cookie file to another PC for access
personal transaction.
>
> >3. When access cc.cgi, I assume the value of cookie (i.e. aaa) would
> >be clear. But I found that if the guy has not access cc.cgi to clear
> >the value but access aa.cgi with re-type new value such as 'orange'.
> >When the guy access bb.cgi, it seems to use the previous value 'apple'
> >not 'orange'. Why ?
>
> don't know without knowing more about how you're setting these cookies
>
>
I expect the cookie value could be overwritten by new value but the result is
still storing the old value. I don't know why it can't work.
> >4. How do I set more secure for avoiding someone to get the value in
> >cookie "aaa' ?
>
> assuming that you're talking about someone in between the server and
> your target user - then you could use an SSL certificate to secure the
> session which would prevent people from intercepting the information
> sent between the server and your target user
>
> but if you're talking about the target user saving the cookie despite
> the fact that you set no expiry - then there's no way to guarantee that
> they don't save it .. you send it to them - it's theirs to save
>
The reason I concern is the PC would be putted in the shop and the customer
can access the PC either checking the outstanding bonus he/she got or make
on-line reservation. So I must consider the security on cookie to protect
such customer when he/she browses another site without logout, his/her
personnel information could not access by another guy when the another guy
know the path name of bonus page and directly locate the bonus page in URL.
>
> >5. Would Perl have allowed to use Session ID rather than cookie?
>
> if you're talking about the SessionID like the one that ASP in Microsoft
> IIS uses - then that is actually implemented using cookies underneath
>
> --
> jason -- elephant@squirrelgroup.com --
------------------------------
Date: Tue, 12 Sep 2000 15:39:12 +1100
From: jason <elephant@squirrelgroup.com>
Subject: Re: Some question in using Perl Cookie from a PERL beginner
Message-Id: <MPG.142850677e8cb3d989787@localhost>
Kit <2kman@lovecat.com> wrote ..
>jason wrote:
>> as was recently discovered in this newsgroup .. this depends on which
>> version of CGI::Cookie you're using
-
>I use ActivePearl currently.
not relevant .. CGI::Cookie versions are independant of which
distribution you are using
>Either setting fixed path or using original path (i.e. not setting fixed
>path), which one would be more secure and better?
the most secure is to set the path as close as you can without
destroying the behaviour that you're after
so if you have three scripts
/cgi-bin/aa.cgi
/cgi-bin/bb.cgi
/cgi-bin/cc.cgi
and all three of them need access to the same cookie .. then the path
that's common between all of them is
/cgi-bin/
and that's what you should set the path attribute of the cookie to ..
but that will also give all the other scripts in the /cgi-bin/ directory
access to the same cookie .. this may - or may not - be a concern to you
>If I expect not to set the path, would it use the default path of browser?
I'm not sure I understand the question .. but if you do not explicitly
set the path attribute of the cookie then you are relying on the
CGI::Cookie module to set it for you .. it will either set it to '/'
which means that all scripts on your server have access to that cookie -
or - it will set it to $ENV{SCRIPT_NAME} which means that only the
script that set the cookie has access to it
it depends on which version of CGI::Cookie that you happen to have on
your server as to which of the above behaviours it will do .. it is
*much* better to set the path attribute of the cookie explicitly to the
value that you want (eg. to '/cgi-bin/')
>Would cookie store at harddisk physically or only store in memory logically
>before reset the cookie value?
here's the thing .. if you set a cookie THEN YOU SEND THAT COOKIE TO THE
USER .. most browsers (if not all) follow the same behaviour that if
there's no expiry date then they do not save the cookie .. BUT .. that
doesn't prevent someone from writing their own browser (in Perl for
instance .. it takes a couple of minutes)
then they can connect to your site .. you send them the cookie .. and
they ignore the expiry date and just save the cookie to a floppy disk
the point is YOU CANNOT RELY ON COOKIES FOR ANY LEVEL OF REAL SECURITY
>I mean if the cookie stores in harddisk during run-time, how to prevent the
>guy getting the cookie and then copy the cookie file to another PC for access
>personal transaction.
see above .. you cannot rely on cookies for any level of real security
.. NOTHING prevents someone from saving a cookie to their disk .. you
send them the cookie - you can't prevent them from saving it
Netscape Navigator and Microsoft Internet Explorer (as well as many
other browsers - if not all) will not save the cookie .. but NOTHING
prevents them from writing their own to grab your cookie
>I expect the cookie value could be overwritten by new value but the result is
>still storing the old value. I don't know why it can't work.
it sounds like you have two cookies .. this would be because the
CGI::Cookie module is setting the path attribute of the cookie to
$ENV{SCRIPT_NAME} which means that each script has it's own cookie
you need to set the path to something a little looser
>The reason I concern is the PC would be putted in the shop and the customer
>can access the PC either checking the outstanding bonus he/she got or make
>on-line reservation. So I must consider the security on cookie to protect
>such customer when he/she browses another site without logout, his/her
>personnel information could not access by another guy when the another guy
>know the path name of bonus page and directly locate the bonus page in URL.
well .. nothing will prevent that anyway .. if the first customer didn't
log out - and they left the browser open .. then a second customer would
still have the same cookie stored in memory
you need to rethink your model .. because cookies cannot be relied upon
for any level of real security (hopefully I've said that enough times
now)
if you're developing this as a commercial application - and you're
asking these sorts of questions - then you should seriously consider
employing a security consultant .. because you sound very much out of
your depth
[ snipped to buggery - sorry - I know I removed a lot of context ]
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Mon, 11 Sep 2000 13:16:02 -0700
From: "Francis Foley" <hoffboy@excite.com>
Subject: Tim Falzone
Message-Id: <8pjemu$1j3$1@paxfeed.eni.net>
Anyone know how I can get in touch with Tim Falzone? I read about him in the
current WIRED (The Geek cruise story) and I've got input re: his image
browser project.
Thanks all.
Foley
------------------------------
Date: Tue, 12 Sep 2000 10:19:51 +0100
From: Nick Condon <nickco3@yahoo.co.uk>
Subject: Re: Unix ps and perl question
Message-Id: <39BDF537.55848E30@yahoo.co.uk>
Phil Barone wrote:
> I have a need to monitor a particular unix process to see if it exists.
>
> Normally I would issue a ps and test the return string for the
> particular process.
>
> As implemented the Args portion of the command can be longer than my
> Solaris ps output gives in response to the ps command. It looks like 75
> or so chars.
>
> Is there a way/method to get the entire process command/args?
>
You have two ps commands on Solaris, the one you want is the other one
/usr/ucb/ps (man -s1b ps) with 'ww' amongst your flags. That will give you
the complete command line with no truncation.
Probably should have posted this to comp.unix.solaris, though.
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 4295
**************************************
