[24017] in Perl-Users-Digest
Perl-Users Digest, Issue: 6215 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 4 14:10:41 2004
Date: Thu, 4 Mar 2004 11:10:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 4 Mar 2004 Volume: 10 Number: 6215
Today's topics:
Re: Perl & Sessions? <jwillmore@remove.adelphia.net>
Re: Perl & Sessions? (another one)
Re: Perl & Sessions? <jwillmore@remove.adelphia.net>
Re: Perl & Sessions? <sbryce@scottbryce.com>
Re: Perl & Sessions? <vetro@online.no>
Re: Perl & Sessions? <usenet@morrow.me.uk>
Re: Perl & Sessions? <vetro@online.no>
Re: Perl & Sessions? <flavell@ph.gla.ac.uk>
Re: Perl & Sessions? <flavell@ph.gla.ac.uk>
Re: Perl & Sessions? <flavell@ph.gla.ac.uk>
Re: Perl & Sessions? ctcgag@hotmail.com
Reaction time source code? <s020274@cuhk.edu.hk>
Re: Reaction time source code? <usenet@morrow.me.uk>
Re: Reaction time source code? <s020274@cuhk.edu.hk>
Re: Reaction time source code? <lallip@dishwasher.cs.rpi.edu>
Re: Removing accents from spanish characters (Walter Roberson)
Re: Slow Sorting $_@_.%_
Re: using C++ from perl <bryan.krone@motorola.com>
Re: webservices <hillmw@ram.lmtas.lmco.com>
Re: webservices <glex_nospam@qwest.invalid>
Re: What with this open file descriptor/"Read on closed (Rex Gustavus Adolphus)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 04 Mar 2004 10:36:43 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Perl & Sessions?
Message-Id: <pan.2004.03.04.15.36.41.170041@remove.adelphia.net>
On Wed, 03 Mar 2004 17:08:21 +0100, Vetle Roeim wrote:
> * James Willmore
> [...]
>>> After a sucessful login I usually send a hard-to-guess string in a
>>> hidden field and then use this to identify the user. The value is held
>>> in a table with a date/time stamp that I update whenever I hear from the
>>> user, or delete after a given period of non-use or a log-off. This
>>> allows the user to do what they like while the identifier is valid -
>>> including reject cookies and maintain multiple sessions. It seems
>>> simpler than cookies and just as secure. Or am I missing something ?
>>
>> Hidden fields are not *really* hidden and can be altered by the user.
>> This is why *most* who do CGI applications don't use hidden fields at all.
>
> But he has basically the same functionality as cookies, only the
> session id is in a form element. Users can alter their cookie values
> too, you know...
Not as easily as they can with hidden values :-) The user can save the
page, alter the hidden value, then submit the page - simple :-)
Basicily, two things to remember about security ....
- the human interface *is* the weakest link in *any* security model
- security is to keep honest people honest; if someone *really* wants to
get around security you have set up, they will find a way (usually,
through the human interface :-) )
So, in the end, nothing says you *have* to favor cookies over hidden
fields, but, IMHO, why make it easier for the human interface to break
down the security you have set up. With cookies, it's more of a chore to
change anything versus hidden fields which is rather trivial and
*anyone* can do it with relative ease.
Just my $0.02
> [...]
>> The bottom line with this whole thing is really rather simple - create an
>> identifer unique for the browser that can can be matched in some way on
>> the server. The identifier *must* be something the user *can not* alter
>> (at least, not easily). Hidden fields is *not* the way to do it.
>
> It's possible to fake cookie values... Session hijacking is still
> possible, whether the session id is in a form element or in a
> cookie.
Ah ... now we're getting into using other mechanisms to prevent this from
occuring - which are done on the server side. Like, storing the
HTTP referer and/or remote host value(s) in the session id file. This,
again, can be circumvented.
As interesting as this thread is, it's now getting to the point that it's
not Perl :-)
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
Health nuts are going to feel stupid someday, lying in hospitals
dying of nothing. -- Redd Foxx
------------------------------
Date: Thu, 04 Mar 2004 15:51:37 +0000
From: "Steve (another one)" <y66y@56yu4b6.com>
Subject: Re: Perl & Sessions?
Message-Id: <c27jaa$h8$1@news.liv.ac.uk>
James Willmore wrote:
> On Wed, 03 Mar 2004 17:08:21 +0100, Vetle Roeim wrote:
>
>
>>* James Willmore
>>[...]
>>
>>>>After a sucessful login I usually send a hard-to-guess string in a
>>>>hidden field and then use this to identify the user. The value is held
>>>>in a table with a date/time stamp that I update whenever I hear from the
>>>>user, or delete after a given period of non-use or a log-off. This
>>>>allows the user to do what they like while the identifier is valid -
>>>>including reject cookies and maintain multiple sessions. It seems
>>>>simpler than cookies and just as secure. Or am I missing something ?
>>>
>>>Hidden fields are not *really* hidden and can be altered by the user.
>>>This is why *most* who do CGI applications don't use hidden fields at all.
>>
>> But he has basically the same functionality as cookies, only the
>> session id is in a form element. Users can alter their cookie values
>> too, you know...
>
>
> Not as easily as they can with hidden values :-) The user can save the
> page, alter the hidden value, then submit the page - simple :-)
>
> Basicily, two things to remember about security ....
> - the human interface *is* the weakest link in *any* security model
> - security is to keep honest people honest; if someone *really* wants to
> get around security you have set up, they will find a way (usually,
> through the human interface :-) )
>
> So, in the end, nothing says you *have* to favor cookies over hidden
> fields, but, IMHO, why make it easier for the human interface to break
> down the security you have set up. With cookies, it's more of a chore to
> change anything versus hidden fields which is rather trivial and
> *anyone* can do it with relative ease.
>
> Just my $0.02
>
>
>>[...]
>>
>>>The bottom line with this whole thing is really rather simple - create an
>>>identifer unique for the browser that can can be matched in some way on
>>>the server. The identifier *must* be something the user *can not* alter
>>>(at least, not easily). Hidden fields is *not* the way to do it.
>>
>> It's possible to fake cookie values... Session hijacking is still
>> possible, whether the session id is in a form element or in a
>> cookie.
>
>
> Ah ... now we're getting into using other mechanisms to prevent this from
> occuring - which are done on the server side. Like, storing the
> HTTP referer and/or remote host value(s) in the session id file. This,
> again, can be circumvented.
>
> As interesting as this thread is, it's now getting to the point that it's
> not Perl :-)
>
>Not as easily as they can with hidden values :-) The user can save the
>page, alter the hidden value, then submit the page - simple :-)
Aaaaarrrrgghh this is going nowhere - changing the hidden value achieves
nothing. You might as well say that a username/password is insecure
because the user can enter anything they like.
------------------------------
Date: Thu, 04 Mar 2004 11:14:15 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Perl & Sessions?
Message-Id: <pan.2004.03.04.16.14.12.411423@remove.adelphia.net>
On Thu, 04 Mar 2004 15:51:37 +0000, Steve (another one) wrote:
> Aaaaarrrrgghh this is going nowhere - changing the hidden value achieves
> nothing. You might as well say that a username/password is insecure
> because the user can enter anything they like.
Well, I wasn't looking for an argument - discussion, yes ... argument, no.
Sorry it appears that way :-(
I agree with you that, if it's a session id in the hidden field that
changing it *may* not do anything but lock out the user (or bad guy).
However, consider this - I have a valid session id in my possession. I
have saved the page that I want to exploit on ye olde hard drive. Now,
it's a trival task to changed the hidden value on the page to match the
valid session id and, bang, I've just hijacked a session.
This does not take into account that you have saved the remote host value
somewhere and are checking this value againist where I'm coming from. Or
using other methods to strengthen security around the site.
The point I was trying to make is simple - hidden values are trival to
change - cookies are not as trivial.
Feel free to disagree. It's really just my experience on the
matter and is not meant to be godspell. However, this discussion is
better left to another group - since it really has nothing to do with Perl :-)
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
"Being disintegrated makes me ve-ry an-gry!" <huff, huff>
------------------------------
Date: Thu, 04 Mar 2004 10:09:53 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Perl & Sessions?
Message-Id: <104eoms6p6ajl38@corp.supernews.com>
Steve (another one) wrote:
> OK I'm convinced that I should re-examine my approach - I will consider
> cookies for future projects.
Same here.
I appreciate the discussion, even if the subject is not directly Perl
related.
------------------------------
Date: Thu, 04 Mar 2004 18:34:35 +0100
From: Vetle Roeim <vetro@online.no>
Subject: Re: Perl & Sessions?
Message-Id: <m31xo8qzx0.fsf@quimby.dirtyhack.org>
* Greg Klinedinst
> On Wed, 03 Mar 2004 21:07:58 +0100, Vetle Roeim <vetro@online.no>
> wrote:
>
>> If you put the session id in the URL, your system may be vulnerable
>> to session hijacking.
>>
>> If the user goes to a page in your system (with the session id in
>> the URL) and clicks a link to an external site, the session id will
>> appear in the referer-header that is sent to the external site.
>>
>> Sverre H. Husebys "Innocent Code" covers this, and much more.
>> <URL:http://innocentcode.thathost.com/>
>
> The user can find out their own session ID in all cases, since in all
> cases it is data they(the client) are sending to your server. The only
> real difference is that with the URL/hidden vars way you don't need to
> worry about the client rejecting cookies.
I don't really see this as a problem... Most users have cookies
enabled, and those who don't know what they're doing and can enable
cookies for sites that require it.
[...]
--
#!/usr/bin/vr
------------------------------
Date: Thu, 4 Mar 2004 17:38:30 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Perl & Sessions?
Message-Id: <c27pin$njh$2@wisteria.csv.warwick.ac.uk>
Vetle Roeim <vetro@online.no> wrote:
>
> I don't really see this as a problem... Most users have cookies
> enabled, and those who don't know what they're doing and can enable
> cookies for sites that require it.
...but may well still choose not to, as they don't trust the site in
question. Speaking as someone who refuses cookies by default, I don't
think that relying on them for session IDs is a good idea. If the ID is
in a field (GET or POST) I have much more control over what you track
and what you don't.
Also note that (I don't know if it ever came to anything) there was talk
of an EU directive banning cookies, as an invasion of privacy...
Ben
--
Razors pain you / Rivers are damp
Acids stain you / And drugs cause cramp. [Dorothy Parker]
Guns aren't lawful / Nooses give
Gas smells awful / You might as well live. ben@morrow.me.uk
------------------------------
Date: Thu, 04 Mar 2004 18:42:50 +0100
From: Vetle Roeim <vetro@online.no>
Subject: Re: Perl & Sessions?
Message-Id: <m3u114pkyt.fsf@quimby.dirtyhack.org>
* James Willmore
>>>> After a sucessful login I usually send a hard-to-guess string in a
>>>> hidden field and then use this to identify the user. The value is held
>>>> in a table with a date/time stamp that I update whenever I hear from the
>>>> user, or delete after a given period of non-use or a log-off. This
>>>> allows the user to do what they like while the identifier is valid -
>>>> including reject cookies and maintain multiple sessions. It seems
>>>> simpler than cookies and just as secure. Or am I missing something ?
>>>
>>> Hidden fields are not *really* hidden and can be altered by the user.
>>> This is why *most* who do CGI applications don't use hidden fields at all.
>>
>> But he has basically the same functionality as cookies, only the
>> session id is in a form element. Users can alter their cookie values
>> too, you know...
>
> Not as easily as they can with hidden values :-) The user can save the
> page, alter the hidden value, then submit the page - simple :-)
Well... In Opera it's easier to edit cookie values than
save-edit-submit. It probides an interface for editing cookie
values.
Personally, I prefer using cookies, but the security gained by using
cookies is IMHO not significant... The practical benefits are
greater.
[...]
--
#!/usr/bin/vr
------------------------------
Date: Thu, 4 Mar 2004 17:48:31 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl & Sessions?
Message-Id: <Pine.LNX.4.53.0403041742460.2777@ppepc56.ph.gla.ac.uk>
On Thu, 4 Mar 2004, Vetle Roeim wrote:
> I don't really see this as a problem... Most users have cookies
> enabled,
"most users" aren't Perl programmers. So if you're only interested
in "most users", why are you here? ;-))
> and those who don't know what they're doing
I think you're missing a significant comma in that sentence!!!
> and can enable cookies
"Can", certainly, but if it's not of proven value to them, they'll
maybe go somewhere else instead...
> for sites that require it.
If they "require" it, then I'll surely go somewhere else. If they
bother to explain why it's going to benefit *me* (i.e more than it
benefits *them*), then I'd be happy to consider it.
cheers
------------------------------
Date: Thu, 4 Mar 2004 18:02:29 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl & Sessions?
Message-Id: <Pine.LNX.4.53.0403041749100.2777@ppepc56.ph.gla.ac.uk>
On Thu, 4 Mar 2004, Ben Morrow wrote:
> Also note that (I don't know if it ever came to anything) there was talk
> of an EU directive banning cookies, as an invasion of privacy...
IANAL, but as I understood it, what is ruled out is attempting to set
a cookie without any explanation of what it's used for.
Google suggests http://www.iabuk.net/index.php?class=news&view=801
One site insisted I had to accept its cookie before it would even
let me read their policy statement! You can guess what I did next...
------------------------------
Date: Thu, 4 Mar 2004 18:43:32 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl & Sessions?
Message-Id: <Pine.LNX.4.53.0403041838410.2777@ppepc56.ph.gla.ac.uk>
On Thu, 4 Mar 2004, Alan J. Flavell wrote:
On Thu, 4 Mar 2004, Vetle Roeim wrote:
[...]
> > and those who don't know what they're doing
>
> I think you're missing a significant comma in that sentence!!!
I'm rightly rebuked by a 3rd party in email: whereas the sentence
really *does* call for something to disambiguate it, the truth is that
a comma wouldn't be the proper way to do it.
Point taken, and I'm happy to correct the record. (Apologies for the
off-topic detail.)
------------------------------
Date: 04 Mar 2004 19:00:32 GMT
From: ctcgag@hotmail.com
Subject: Re: Perl & Sessions?
Message-Id: <20040304140032.444$rN@newsreader.com>
Scott Bryce <sbryce@scottbryce.com> wrote:
>
> The reason I lean toward URL munging/hidden fields is that users can
> choose not to accept cookies. If a user does not accept your cookie, you
> cannot identify the session later on. The user does not have the option
> of rejecting your hidden fields.
If the user rejects the cookies, that is their decision--presumably they
made it for a reason. Why should I set about circumventing their decision
by using hidden fields?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 5 Mar 2004 01:41:15 +0800
From: "Tsui Wai-ming" <s020274@cuhk.edu.hk>
Subject: Reaction time source code?
Message-Id: <c27pam$1f3b$1@justice.itsc.cuhk.edu.hk>
Has anyone written a program for recording reaction time, like those used in
psychology experiments?
I've seen some written in C/C++ but I don't know C languages... :(
Ming~
------------------------------
Date: Thu, 4 Mar 2004 17:39:02 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Reaction time source code?
Message-Id: <c27pjm$njh$3@wisteria.csv.warwick.ac.uk>
"Tsui Wai-ming" <s020274@cuhk.edu.hk> wrote:
> Has anyone written a program for recording reaction time, like those used in
> psychology experiments?
>
> I've seen some written in C/C++ but I don't know C languages... :(
Should be pretty trivial using Time::HiRes...
Ben
--
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
/Alcestis/) [ flame, and falls out of sight. ] ben@morrow.me.uk
------------------------------
Date: Fri, 5 Mar 2004 02:05:49 +0800
From: "Tsui Wai-ming" <s020274@cuhk.edu.hk>
Subject: Re: Reaction time source code?
Message-Id: <c27qon$1g2d$1@justice.itsc.cuhk.edu.hk>
"Ben Morrow" <usenet@morrow.me.uk> ¼¶¼g©ó¶l¥ó·s»D
:c27pjm$njh$3@wisteria.csv.warwick.ac.uk...
>
> "Tsui Wai-ming" <s020274@cuhk.edu.hk> wrote:
> > Has anyone written a program for recording reaction time, like those
used in
> > psychology experiments?
> >
> > I've seen some written in C/C++ but I don't know C languages... :(
>
> Should be pretty trivial using Time::HiRes...
Thanks for your message. But could you tell me where I can find some
information on Time::HiRes? I've just searched through my Perl Bookshelf
(Perl in a Nutshell, Learning Perl on Win32 Systems, Programming Perl) and I
wasn't able to locate it :'(
------------------------------
Date: Thu, 4 Mar 2004 13:14:06 -0500
From: Paul Lalli <lallip@dishwasher.cs.rpi.edu>
Subject: Re: Reaction time source code?
Message-Id: <20040304131349.K27834@dishwasher.cs.rpi.edu>
On Fri, 5 Mar 2004, Tsui Wai-ming wrote:
> "Ben Morrow" <usenet@morrow.me.uk> =BC=B6=BCg=A9=F3=B6l=A5=F3=B7s=BBD
> :c27pjm$njh$3@wisteria.csv.warwick.ac.uk...
> >
> > "Tsui Wai-ming" <s020274@cuhk.edu.hk> wrote:
> > > Has anyone written a program for recording reaction time, like those
> used in
> > > psychology experiments?
> > >
> > > I've seen some written in C/C++ but I don't know C languages... :(
> >
> > Should be pretty trivial using Time::HiRes...
>
> Thanks for your message. But could you tell me where I can find some
> information on Time::HiRes? I've just searched through my Perl Bookshelf
> (Perl in a Nutshell, Learning Perl on Win32 Systems, Programming Perl) an=
d I
> wasn't able to locate it :'(
>
http://www.cpan.org Learn it, use it, love it.
------------------------------
Date: 4 Mar 2004 16:37:58 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: Removing accents from spanish characters
Message-Id: <c27m16$mph$1@canopus.cc.umanitoba.ca>
In article <c277or$1pn8k4$1@ID-184292.news.uni-berlin.de>,
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
: s/Þ/Th/;
: s/Æ/Ae/;
: s/þ/th/;
: s/æ/ae/;
What if there's more than one thorn in the text? Should those s//'s not
have /g ?
--
Preposterous!! Where would all the calculators go?!
------------------------------
Date: Thu, 04 Mar 2004 15:29:36 GMT
From: $_@_.%_
Subject: Re: Slow Sorting
Message-Id: <AXH1c.36573$TF2.5307@nwrdny02.gnilink.net>
>
><$_@_.%_> wrote in message news:fYx1c.7677$YN5.4930@nwrdny03.gnilink.net...
>>
>> This sort runs pretty slowly, any hints on how to speed this up?
>>
>> foreach my $k (sort {$file{$b}[$col] cmp $file{$a}[$col]}
>> keys %file)
>>
>> %file is a 'HoA', there are usually around 500 keys.
>> Each {key} has an anonymous [array] with 8 items.
>> The item data is mixed.. numbers, punctuation, letters.
>
>you probably are doing something wrong
>this should not take a long time
>
>gnari
That is indeed the offending line. Here is the entire subroutine.
sub lb2_msg_sort1 #-------------------------------------------------
{
my $col = $_[0]; my $t; $sort_cnt++;
$mw->Busy(-recurse => 1,);
my $chek_enc =
'Qk1YAgAAAAAAADYAAAAoAAAACgAAABEAAAABABgAAAAAAAAAAAASCwAAEgsAAA'.
'AAAAAAAAAA////////////////////////////////////////AAD4+Pj/////'.
'//////////////////////////////8AAP////////////////////////////'.
'39/f39/fj4+AAA////////////////////////////////////////AAD/////'.
'///+/v7+/v79/f39/f3+/v7///////////8AAGZHumlKvUYvi4p0xotyzVhEkm'.
'BFp1w8sP38/v///wAAdlfK////////9fL79fP8+vj//fz/i3LN+vn9////AABm'.
'R7r49//4+/9JTFsXGCGvr7b///9sU7X////9/f8AAGZHuvHu/sPG1RYZKBobKx'.
'AQFGFedGFHrPz8/f79/wAAa0+6/Pv/Xl5mAAAIq6yyJygrAAASZE6i+/v9/v7/'.
'AAByWLv49f/R0NfLy9Dw8PStrrUHBhBRP4P///////8AAHNVv/v6/fXy+vj3/P'.
'Lv+vHv+RcSJgUDCO/v7////wAAgGTGeV3AlX3RhGjLi3LNi3LNdlrAIiElDQsT'.
'7+/vAAD///3///7+/f/////////////9/fz39/clJyPQ0NAAAP////////////'.
'///////////////////////////wAA/v7+////////////////////////+/v7'.
'////+Pj5AAD////////+/v7+/v7+/v7////////////////7/PsAAAAA';
my $chek = $mw->Photo(-format => 'bmp', -data => $chek_enc);
undef $chek_enc;
#load group file
my %file;
if (-e "$grp.grp") {
open (FH, "< $grp.grp") or &error('sort_1');
my @msgs = (<FH>); close FH;
foreach my $line (@msgs) {
my @a = split ('~::~', $line); my $k = shift @a;
$file{$k}[0] = "$a[0]"; $file{$k}[1] = "$a[1]";
$file{$k}[2] = "$a[2]"; $file{$k}[3] = "$a[3]";
$file{$k}[4] = "$a[4]"; $file{$k}[5] = "$a[5]";
$file{$k}[6] = "$a[6]"; $file{$k}[7] = "$a[7]";
} }
$lb2_msg->delete('all');
if ($sort_cnt % 2) {
foreach my $k (sort {$file{$b}[$col] cmp $file{$a}[$col]}
keys %file)
{
#re-populate
my ($lb2_k1, $lb2_k2,);
if ($file{$k}[4] eq 'old') {
$lb2_k1 = $lb2_msg->ItemStyle('text', -anchor => 'e',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => '#000000',
-font => '{Arial} 8',);
$lb2_k2 = $lb2_msg->ItemStyle('text', -anchor => 'w',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => '#000000',
-font => '{Arial} 8',);
}else{
$lb2_k1 = $lb2_msg->ItemStyle('text', -anchor => 'e',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => 'blue',
-font => '{Arial} 8',);
$lb2_k2 = $lb2_msg->ItemStyle('text', -anchor => 'w',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => 'blue',
-font => '{Arial} 8',);
}
if (!defined $t || Tk::timeofday()-$t > 10)
{$mw->update; $t = Tk::timeofday();}
$lb2_msg->add($k);
$lb2_msg->itemCreate($k, 0, -itemtype => 'text',
-style => $lb2_k2,
-text => "$file{$k}[0]",);
$lb2_msg->itemCreate($k, 1, -itemtype => 'text',
-style => $lb2_k2,
-text => "$file{$k}[1]");
$lb2_msg->itemCreate($k, 2, -itemtype => 'text',
-style => $lb2_k1,
-text => "$file{$k}[6]");
$lb2_msg->itemCreate($k, 3, -itemtype => 'text',
-style => $lb2_k1,
-text => "$file{$k}[5]");
$lb2_msg->itemCreate($k, 4, -itemtype => 'text',
-style => $lb2_k1,
-text => "$file{$k}[2]");
if ($file{$k}[7] eq 'read') {
$lb2_msg->indicator('create', $k, -itemtype => 'image',
-image => $chek);
}}}else{
foreach my $k (sort {$file{$a}[$col] cmp $file{$b}[$col]}
keys %file)
{
#re-populate
my ($lb2_k1, $lb2_k2,);
if ($file{$k}[4] eq 'old') {
$lb2_k1 = $lb2_msg->ItemStyle('text', -anchor => 'e',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => '#000000',
-font => '{Arial} 8',);
$lb2_k2 = $lb2_msg->ItemStyle('text', -anchor => 'w',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => '#000000',
-font => '{Arial} 8',);
}else{
$lb2_k1 = $lb2_msg->ItemStyle('text', -anchor => 'e',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => 'blue',
-font => '{Arial} 8',);
$lb2_k2 = $lb2_msg->ItemStyle('text', -anchor => 'w',
-selectforeground => '#fff000',
-background => '#ffffff',
-foreground => 'blue',
-font => '{Arial} 8',);
}
if (!defined $t || Tk::timeofday()-$t > 10)
{$mw->update; $t = Tk::timeofday();}
$lb2_msg->add($k);
$lb2_msg->itemCreate($k, 0, -itemtype => 'text',
-style => $lb2_k2,
-text => "$file{$k}[0]",);
$lb2_msg->itemCreate($k, 1, -itemtype => 'text',
-style => $lb2_k2,
-text => "$file{$k}[1]");
$lb2_msg->itemCreate($k, 2, -itemtype => 'text',
-style => $lb2_k1,
-text => "$file{$k}[6]");
$lb2_msg->itemCreate($k, 3, -itemtype => 'text',
-style => $lb2_k1,
-text => "$file{$k}[5]");
$lb2_msg->itemCreate($k, 4, -itemtype => 'text',
-style => $lb2_k1,
-text => "$file{$k}[2]");
if ($file{$k}[7] eq 'read') {
$lb2_msg->indicator('create', $k, -itemtype => 'image',
-image => $chek);
}}}$mw->Unbusy;
}
------------------------------
Date: Thu, 04 Mar 2004 09:00:30 -0600
From: Bryan Krone <bryan.krone@motorola.com>
Subject: Re: using C++ from perl
Message-Id: <4047448E.81FC1862@motorola.com>
Sergei Emantayev wrote:
>
> Hello, dear all!
> My question is about using C++ classes from Perl.
> Is it possible to create and manage c++ objects in perl?
> Is there any helper libraries like boost.python?
Inline::CPP
------------------------------
Date: Thu, 04 Mar 2004 11:07:57 -0600
From: Michael Hill <hillmw@ram.lmtas.lmco.com>
To: gnari <gnari@simnet.is>
Subject: Re: webservices
Message-Id: <4047626D.8E114B1B@ram.lmtas.lmco.com>
I did some trouble shooting and found some problems in script.pl and
made the changes.
I ran the script from the telnet prompt. The output from script.pl is:
#<file>
# <stuff>
# <stuffa>yep stuff here</stuffa>
# <stuffb>
# <nestedstuff>and nested here</nestedstuff>
# </stuffb>
# </stuff>
#</file>
The webservices script is as below and produced "HASH(0x3732b0)" in the
browser. This is telling me that $stuff consists of a hash.
I modified the section to see the contents of the hash but it is not
printing anything, so I am stumped there:
my %stuff;
my $stuff = $xs->XMLin( $content );
foreach my $x ( keys %stuff )
{
foreach my $y ( $stuff{$x} )
{
print " $x, $y\n";
}
}
**************************************************************************
use strict;
# Create a user agent object
use LWP::UserAgent;
use XML::Simple;
#define the user agent
my $ua = new LWP::UserAgent();
my $request = new
HTTP::Request('get','http://blah.blah.blah../script.pl');
my $result = $ua->request($request);
#set-up the html and fetch the results
print "Content-type:text/html\n\n";
print "<HTML><HEAD><TITLE>test title</TITLE></HEAD><body>";
if ( $result->is_success )
{
my $content = $result->content;
die "ooops: wierd result [$content]"
unless $content=~/^<file>.*<\/file>/s;
my $xs = XML::Simple->new();
my $stuff = $xs->XMLin( $content );
print "$stuff";
}
else
{
print "was not successful\n";
}
print "</BODY></HTML>\n";
------------------------------
Date: Thu, 04 Mar 2004 12:10:21 -0600
From: "J. Gleixner" <glex_nospam@qwest.invalid>
Subject: Re: webservices
Message-Id: <iiK1c.31$RQ.30920@news.uswest.net>
Michael Hill wrote:
> I did some trouble shooting and found some problems in script.pl and
> made the changes.
>
> I ran the script from the telnet prompt. The output from script.pl is:
> #<file>
> # <stuff>
> # <stuffa>yep stuff here</stuffa>
> # <stuffb>
> # <nestedstuff>and nested here</nestedstuff>
> # </stuffb>
> # </stuff>
> #</file>
verbatim? The leading # will mess-up any parsing because it's not
valid XML. If this is the case, you'll need to remove them before
passing it to XMLin().
>
> The webservices script is as below and produced "HASH(0x3732b0)" in the
> browser. This is telling me that $stuff consists of a hash.
XMLin returns a hash reference. See the docs for XML::Simple. You
could use Data::Dumper to see the data in $stuff. That way you can see
excatly how the data is stored in $stuff.
>
> I modified the section to see the contents of the hash but it is not
> printing anything, so I am stumped there:
> my %stuff;
Not needed.. $stuff and %stuff are two different things and %stuff is
never set to anything.
> my $stuff = $xs->XMLin( $content );
> foreach my $x ( keys %stuff )
$stuff is a reference.. need to use %$stuff
> {
> foreach my $y ( $stuff{$x} )
$stuff is still a reference. If $stuff->{$x} is an array, then you'd use:
foreach my $y ( @{ $stuff->{$x} } )
> {
> print " $x, $y\n";
> }
> }
Can also check to see if it parsed without errors.
my $stuff = eval { $xmls->XMLin($content) };
die "Couldn't parse $xml: $@" if $@;
Could also print $content.. Ya need to encode the various HTML looking
tags (perldoc HTML::Entities encode_entities) for it to show up in your
browser, or you can 'View Source' to see the (hopefully) well-formed XML.
------------------------------
Date: 4 Mar 2004 07:31:20 -0800
From: uffesterner@spamhole.com (Rex Gustavus Adolphus)
Subject: Re: What with this open file descriptor/"Read on closed filehandle " stuff?
Message-Id: <c70a85ff.0403040731.520c1b02@posting.google.com>
"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message news:<c273gt$4o2$1@nets3.rz.RWTH-Aachen.DE>...
> Also sprach Rex Gustavus Adolphus:
>
> > Ben Morrow <usenet@morrow.me.uk> wrote in message news:<c14sju$c84$1@wisteria.csv.warwick.ac.uk>...
> >> uffesterner@spamhole.com (Rex Gustavus Adolphus) wrote:
> >> >
<snip>
> >
> > I forgot to mention it in my first post, but more often than not
> > there's
> > actually no need to glob() at all since $filename seldom contains
> > wildcards.
> >
> > I change this code
> > @files = glob($filename);
> > to this:
> > $_ = $filename;
> > # check for existence of ? and/or *
> > if ( m/.*[\?|\*].*/ ) {
> > @files = glob($filename);
> > } else {
> > push(@files,$filename);
> > }
> >
> > It's not a perfect solution, but will at least make the number of
> > glob()-call much less.
>
> Be aware however, that your regex is too simpleminded. It doesn't catch
> (for instance):
>
> file.[ch]
>
> whereas it (falsely) does catch
>
> file\*.c
>
> In the latter, the asterics is escaped and thus to be taken as a literal
> literally.
Yes, you're correct of course.
Someone must have solved this foolproof before.
I guess it's not as simple as requiring the character before * (or ?)
is not a backslash since this should be catched, or?:
file\\*.c
>
> Tassilo
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 6215
***************************************
