[31478] in Perl-Users-Digest
Perl-Users Digest, Issue: 2730 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 18 16:09:48 2009
Date: Fri, 18 Dec 2009 13:09:13 -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 Fri, 18 Dec 2009 Volume: 11 Number: 2730
Today's topics:
Re: cpan errors <smallpond@juno.com>
Re: Creating an alias to an existing hash (from a hash <derykus@gmail.com>
Re: Creating an alias to an existing hash (from a hash <jl_post@hotmail.com>
Re: Creating an alias to an existing hash (from a hash <jl_post@hotmail.com>
Re: Creating an alias to an existing hash (from a hash <jl_post@hotmail.com>
Re: Creating an alias to an existing hash (from a hash <derykus@gmail.com>
Re: Creating an alias to an existing hash (from a hash <xhoster@gmail.com>
Re: Creating an alias to an existing hash (from a hash <jl_post@hotmail.com>
Difference between "$var" and $var? sharma__r@hotmail.com
Re: Difference between "$var" and $var? sharma__r@hotmail.com
Re: Difference between "$var" and $var? <uri@StemSystems.com>
Re: Difference between "$var" and $var? <OJZGSRPBZVCX@spammotel.com>
Re: Difference between "$var" and $var? sharma__r@hotmail.com
Re: Difference between "$var" and $var? sharma__r@hotmail.com
Re: Difference between "$var" and $var? <john@castleamber.com>
Re: Difference between "$var" and $var? <jl_post@hotmail.com>
Re: Difference between "$var" and $var? <uri@StemSystems.com>
Re: Difference between "$var" and $var? <uri@StemSystems.com>
Re: FAQ 8.21 Where do I get the include files to do ioc <justin.0912@purestblue.com>
Re: Opening a file with case-insensitive name <e9427749@stud4.tuwien.ac.at>
Re: WWW::Mechanize <brandon.n.atkinson@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 18 Dec 2009 14:42:25 -0500
From: Steve C <smallpond@juno.com>
Subject: Re: cpan errors
Message-Id: <hgglvh$3vk$1@news.eternal-september.org>
Ruben Safir wrote:
> On Thu, 17 Dec 2009 11:58:53 -0500, Steve C wrote:
>
>> Ruben Safir wrote:
>>> I have a new distro of openSuse and cpan seems to be not working.
>
There is this error:
Use of uninitialized value $file_length in concatenation (.) or string
at /usr/lib/perl5/vendor_perl/5.10.0/LWP/UserAgent.pm line 847.
and this:
> untarred my development environment from perl 5.8,
Could you have mixed something between perl 5.8 and 5.10?
If you have a ~/.cpan/ or ~root/.cpan/ directory from 5.8, just remove
it and let CPAN start from scratch.
------------------------------
Date: Fri, 18 Dec 2009 05:56:19 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <e10a1721-47cd-4797-83a5-528961079eb6@g22g2000prf.googlegroups.com>
On Dec 17, 2:52=A0pm, "jl_p...@hotmail.com" <jl_p...@hotmail.com> wrote:
> ...
> =A0 =A0However, since his code had "use strict;" in effect, "perl -c"
> responded with:
>
> Variable "%hash" is not imported at ...
>
> So I declared %hash the line before with "my", like this:
>
> =A0 =A0my %hash;
> =A0 =A0local *hash =3D $hashRef;
>
> =A0 =A0That didn't work; although it compiled just fine, %hash was empty.
> So then I changed it to be declared with "our" instead of "my", like
> this:
>
> =A0 =A0our %hash;
> =A0 =A0local *hash =3D $hashRef;
>
> and that worked. =A0From then on in that function, every instance of
> %hash pointed back to the passed-in %hash (that was passed in as a
> reference).
I was glad to hear about Data::Alias which's the way to go.
However, 'no strict', used sparingly, may make sense in some
cases too, particularly as an 'our' alternative:
{ no strict; local *hash =3D $hashRef; $hash{...} =3D ...; }
--
Charles DeRykus
------------------------------
Date: Fri, 18 Dec 2009 08:32:38 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <459be193-cc1e-433e-80f8-19420a132395@j24g2000yqa.googlegroups.com>
On Dec 18, 6:56=A0am, "C.DeRykus" <dery...@gmail.com> wrote:
> On Dec 17, 2:52=A0pm, "jl_p...@hotmail.com" <jl_p...@hotmail.com> > I was=
glad to hear about Data::Alias which's the way to go.
> However, 'no strict', used sparingly, may make sense in some
> cases too, particularly as an 'our' alternative:
>
> { no strict; local *hash =3D $hashRef; $hash{...} =3D ...; }
Actually, I'm pretty sure that, when "no strict" is in effect, all
non-declared variables are automatically treated as package variables
(that is, as if they were declared with "our").
So it's not really an alternative to "our"; instead, that's all
you'd be using (unless, of course, you explicitly use "my").
(I tested it out with the following example:
1. I started the Perl interpreter with: perl -wde 1
2. Then I typed:
use strict; { no strict; *blah =3D \%ENV; }
3. Then I was able to reference %ENV through %blah outside
of the scope %blah was fist used in, like this:
print $blah{PATH};
So disabling "strict" doesn't avoid the hazards of using "our",
unfortunately.)
And I agree with you that Data::Alias is definitely the way to go.
I just wish it was a standard module so it could be used without
having to install it explicitly.
-- Jean-Luc
------------------------------
Date: Fri, 18 Dec 2009 11:15:27 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <45bdef92-9984-4a23-b166-0319a7f77e36@y24g2000yqb.googlegroups.com>
On Dec 17, 4:52=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> =A0 =A0 use Data::Alias;
>
> =A0 =A0 sub f {
> =A0 =A0 =A0 =A0 my ($hashRef) =3D @_;
> =A0 =A0 =A0 =A0 alias my %hash =3D %$hashref;
> =A0 =A0 =A0 =A0 ...;
> =A0 =A0 }
Thanks, Ben, yet again! I just installed Data::Alias from CPAN,
and it works great.
It would be nice if it were a standard module, so I could freely
use it on code that is supposed to run on plain Perl installations
(where I have no control over which Perl modules are installed).
If I find myself in such a situation in the future (which I'm sure
will happen), I'll probably just resort to search-and-replacing
instances of "$hash{" to "$hashRef->{".
But if I'm in a situation where I'm free to use CPAN modules, I'll
probably be making good use of Data::Alias.
Thanks again, Ben.
-- Jean-Luc
------------------------------
Date: Fri, 18 Dec 2009 11:35:20 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <e0586b35-c5d2-4f74-bb96-d89e34872c2f@s31g2000yqs.googlegroups.com>
> On Thu, 17 Dec 2009 14:52:16 -0800, jl_p...@hotmail.com wrote:
> > The idea of creating a new variable named %hash came to mind:
>
> > sub f
> > {
> > =A0 =A0my ($hashRef) =3D @_;
> > =A0 =A0my %hash =3D %$hashRef;
> > =A0 =A0.
> > =A0 =A0.
> > =A0 =A0.
> > }
>
> > but that would create a completely new copy of the original
> > %hash (using extra memory),
On Dec 17, 7:54 pm, Ruben Safir <ru...@mrbrklyn.com> wrote:
> Oh.. - why do you say that?
Because when you make a copy of a hash, a completely separate copy
is made. Consider this code:
my %hash =3D %ENV;
or even:
my $hashRef =3D \%ENV;
my %hash =3D %$hashRef;
With either approach, %hash is now equivalent to %ENV, but only
temporarily, since it is a completely separate hash. If you add a new
entry to %hash, like this:
$hash{apple} =3D 'banana';
that same entry won't exist in %ENV. Likewise, if %ENV is modified
(for whatever reason), that modification won't carry over to %hash.
I hope this clarifies things, Ruben.
-- Jean-Luc
------------------------------
Date: Fri, 18 Dec 2009 11:55:59 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <c08fe380-2241-4fcf-941f-24fa7cdc5a4f@a10g2000pre.googlegroups.com>
On Dec 18, 8:32=A0am, "jl_p...@hotmail.com" <jl_p...@hotmail.com> wrote:
> On Dec 18, 6:56=A0am, "C.DeRykus" <dery...@gmail.com> wrote:
>
> > On Dec 17, 2:52=A0pm, "jl_p...@hotmail.com" <jl_p...@hotmail.com> > I w=
as glad to hear about Data::Alias which's the way to go.
> > However, 'no strict', used sparingly, may make sense in some
> > cases too, particularly as an 'our' alternative:
>
> > { no strict; local *hash =3D $hashRef; $hash{...} =3D ...; }
>
> =A0 =A0Actually, I'm pretty sure that, when "no strict" is in effect, all
> non-declared variables are automatically treated as package variables
> (that is, as if they were declared with "our").
>
No, ordinary package variables and those declared with
'our' are scoped differently. And 'our' can be clobbered
in a multi-package global way that ordinary package
variables won't be:
perl -Mstrict -wle "package main; our $x=3D1;
package Foo; our $x=3D2;
package main; print $x"
2
vs.
perl -Mstrict -wle "package main; use vars '$x';$x=3D1;
package Foo; use vars '$x';$x=3D2;
package main; print $x"
1
>
> =A0 =A0So it's not really an alternative to "our"; instead, that's all
> you'd be using (unless, of course, you explicitly use "my").
>
> =A0 =A0(I tested it out with the following example:
>
> 1. I started the Perl interpreter with: =A0perl -wde 1
>
> 2. Then I typed:
>
> =A0 =A0 =A0 use strict; { no strict; *blah =3D \%ENV; }
>
> 3. Then I was able to reference %ENV through %blah outside
> =A0 =A0of the scope %blah was fist used in, like this:
>
> =A0 =A0 =A0 print $blah{PATH};
>
> =A0 =A0So disabling "strict" doesn't avoid the hazards of using "our",
> unfortunately.)
>
Hm, you didn't declare 'blah' or localize inside the
{no strict;...} so that won't compile outside of the
debugger:
perl -Mstrict -le "{no strict; *blah =3D \%ENV;}
print $blah{PATH}"
Variable "%blah" is not imported ...
Global symbol "%blah" requires explicit package name...
But with those corrections, the first print below
works as expected and the final print outside the
{no strict;...} draws an uninitialized warning:
perl -Mstrict -wle "use vars '%blah';
{no strict; local *blah =3D \%ENV; print $blah{PATH};}
print $blah{PATH}"
--
Charles DeRykus
------------------------------
Date: Fri, 18 Dec 2009 12:09:53 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <4b2be9dd$0$7878$ed362ca5@nr5-q3a.newsreader.com>
jl_post@hotmail.com wrote:
> If I find myself in such a situation in the future (which I'm sure
> will happen), I'll probably just resort to search-and-replacing
> instances of "$hash{" to "$hashRef->{".
Don't forget about replacing "@hash{" with "@{$hashRef}{", and "keys
%hash" with "keys %$hashRef", etc.
Xho
------------------------------
Date: Fri, 18 Dec 2009 12:57:47 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Creating an alias to an existing hash (from a hash reference)
Message-Id: <ef8492f5-90f1-4aad-afde-ce7d384e19e0@v25g2000yqk.googlegroups.com>
On Dec 18, 12:55=A0pm, "C.DeRykus" <dery...@gmail.com> wrote:
> the first print below
> works =A0as expected and the final print outside the
> {no strict;...} draws an uninitialized warning:
>
> perl -Mstrict -wle "use vars '%blah';
> =A0 =A0 =A0 {no strict; local *blah =3D \%ENV; print $blah{PATH};}
> =A0 =A0 =A0 print $blah{PATH}"
True, but the uninitialized warning happened because you used the
"local" keyword. If you remove that, then the second print() line
will have access to %ENV via %blah.
So you might think that using "local" prevents code in outside
scopes from accessing %ENV through %blah. But that's not true. The
"local" keyword temporarily changes the value of %blah, but it changes
it everywhere in the package, not just in its scope.
Consider this code:
perl -Mstrict -wle "{no strict; local *blah =3D \%ENV; f() }
sub f { our %blah; print $blah{PATH} }
Even though the code inside f() is in a completely different scope
that the code that calls f(), the code inside f() still has access to
%blah as the calling code sees it (and therefore has access to modify
%ENV through it).
Sure, declaring *blah as "local" in f() would prevent that from
happening, but since you can't always guarantee that all code will
"local"ize all its typeglobs, declaring one typeglob as "local" won't
necessarily stop all code (outside the intended scope) from accessing
what %blah references. (It'll stop some code, but not all code.)
Cheers,
-- Jean-Luc
------------------------------
Date: Fri, 18 Dec 2009 10:42:34 -0800 (PST)
From: sharma__r@hotmail.com
Subject: Difference between "$var" and $var?
Message-Id: <10abdc49-b90b-4fdf-bcb8-18710d2c109e@b36g2000prf.googlegroups.com>
Hi,
Is there any advantage in the assignment operation
$dest = "$src" over
$dest = $src ?
And then, are the following operations identical?
$dest = "$varA:$varB:$varC";
$dest = join ":", $varA, $varB, $varC;
Regards,
--Rakesh
------------------------------
Date: Fri, 18 Dec 2009 10:55:55 -0800 (PST)
From: sharma__r@hotmail.com
Subject: Re: Difference between "$var" and $var?
Message-Id: <a0a65523-5639-41bc-b182-facc23f862a0@m7g2000prd.googlegroups.com>
On Dec 18, 11:48=A0pm, Andrew DeFaria <And...@DeFaria.com> wrote:
> On 12/18/2009 11:42 AM,sharma__r@hotmail.comwrote:Hi,
> Is there any advantage in the assignment operation
> $dest =3D "$src" over
> $dest =3D $src ?I'd say there might be a slight advantaged of:$dest =3D $=
srcover$dest =3D "$src"in that I believe the later will do a needless parse=
of the string expression.And then, are the following operations identical?
> $dest =3D "$varA:$varB:$varC";
> $dest =3D join ":", $varA, $varB, $varC;Yes.--Andrew DeFariaI used up all=
my sick days, so now I'm calling in dead.
What advantage is there? Would you explain some more.
And why then does that advantage not happen in case
of the 'join' example?
--Rakesh
------------------------------
Date: Fri, 18 Dec 2009 14:14:40 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Difference between "$var" and $var?
Message-Id: <87iqc4xffj.fsf@quad.sysarch.com>
>>>>> "sr" == sharma r <sharma__r@hotmail.com> writes:
sr> Hi,
sr> Is there any advantage in the assignment operation
sr> $dest = "$src" over
sr> $dest = $src ?
this has been covered many times here in particular by tad. the "$src"
is not good in general. it makes an unneeded extra copy of the value. it
also can be a bug in that it stringifies the value and since it is a
copy, if a sub wanted to modify it in place, it would fail. the rule is
not to quote single scalar variables unless you really want a copy.
sr> And then, are the following operations identical?
sr> $dest = "$varA:$varB:$varC";
sr> $dest = join ":", $varA, $varB, $varC;
did you compare the results? did you see any differences? make up your
own mind about that.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 18 Dec 2009 20:15:57 +0100
From: "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com>
Subject: Re: Difference between "$var" and $var?
Message-Id: <op.u45egvpjmk9oye@frodo>
On Fri, 18 Dec 2009 19:55:55 +0100, <sharma__r@hotmail.com> wrote:
> What advantage is there? Would you explain some more.
They are just different from each other.
$a = $b simply assigns $b to $a, no matter what $b is. If $b==undef, then
$a will be assigned undef. If $b is a reference to something, $a will be
the same reference.
$a = "$b" transforms $b into a string and then assigns that string to $a.
When $b==undef, then $a will still be assigned "". So there can be a
difference between $a and $b afterwards. If $b is a reference to
something, $a will be the string "HASH(0x1239234)" or whatever, that is,
something totally different.
> And why then does that advantage not happen in case
> of the 'join' example?
'perldof -f join' says "Joins the separate strings of LIST into a single
string". So join transforms the variables it is joining into strings
anyway, so it doesn't differ from "$a:$b:$c".
------------------------------
Date: Fri, 18 Dec 2009 11:26:45 -0800 (PST)
From: sharma__r@hotmail.com
Subject: Re: Difference between "$var" and $var?
Message-Id: <bb5e4d72-7766-40ce-a63f-0fac1a1bd167@13g2000prl.googlegroups.com>
On Dec 19, 12:14=A0am, "Uri Guttman" <u...@StemSystems.com> wrote:
> >>>>> "sr" =3D=3D sharma r <sharma...@hotmail.com> writes:
>
> =A0 sr> Hi,
> =A0 sr> Is there any advantage in the assignment operation
> =A0 sr> =A0 $dest =3D "$src" over
> =A0 sr> =A0 $dest =3D $src =A0 =A0?
>
> this has been covered many times here in particular by tad. the "$src"
> is not good in general. it makes an unneeded extra copy of the value. it
> also can be a bug in that it stringifies the value and since it is a
> copy, if a sub wanted to modify it in place, it would fail. the rule is
> not to quote single scalar variables unless you really want a copy.
>
> =A0 sr> And then, are the following operations identical?
> =A0 sr> =A0 $dest =3D "$varA:$varB:$varC";
> =A0 sr> =A0 $dest =3D join ":", $varA, $varB, $varC;
>
> did you compare the results? did you see any differences? make up your
> own mind about that.
>
> uri
>
> --
> Uri Guttman =A0------ =A0u...@stemsystems.com =A0-------- =A0http://www.s=
ysarch.com--
> ----- =A0Perl Code Review , Architecture, Development, Training, Support =
------
> --------- =A0Gourmet Hot Cocoa Mix =A0---- =A0http://bestfriendscocoa.com=
---------
I didnt see any difference in "$var" & $var. So does that mean there's
no difference?
------------------------------
Date: Fri, 18 Dec 2009 11:27:19 -0800 (PST)
From: sharma__r@hotmail.com
Subject: Re: Difference between "$var" and $var?
Message-Id: <609656c0-a55f-4beb-bf8f-0b15f2959471@w19g2000pre.googlegroups.com>
On Dec 19, 12:15=A0am, "Jochen Lehmeier" <OJZGSRPBZ...@spammotel.com>
wrote:
> On Fri, 18 Dec 2009 19:55:55 +0100, <sharma...@hotmail.com> wrote:
> > What advantage is there? Would you explain some more.
>
> They are just different from each other.
>
> $a =3D $b simply assigns $b to $a, no matter what $b is. If $b=3D=3Dundef=
, then =A0
> $a will be assigned undef. If $b is a reference to something, $a will be =
=A0
> the same reference.
>
> $a =3D "$b" transforms $b into a string and then assigns that string to $=
a. =A0
> When $b=3D=3Dundef, then $a will still be assigned "". =A0So there can be=
a =A0
> difference between $a and $b afterwards. If $b is a reference to =A0
> something, $a will be the string "HASH(0x1239234)" or whatever, that is, =
=A0
> something totally different.
>
> > And why then does that advantage not happen in case
> > of the 'join' example?
>
> 'perldof -f join' says "Joins the separate strings of LIST into a single =
=A0
> string". So join transforms the variables it is joining into strings =A0
> anyway, so it doesn't differ from "$a:$b:$c".
Thanks for clarifying my doubts.
-- Rakesh
------------------------------
Date: Fri, 18 Dec 2009 13:35:17 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Difference between "$var" and $var?
Message-Id: <87skb8ulca.fsf@castleamber.com>
"Uri Guttman" <uri@StemSystems.com> writes:
> did you compare the results? did you see any differences? make up your
> own mind about that.
I think that's a bit unfair. I mean, you *don't* have to post a reply.
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
------------------------------
Date: Fri, 18 Dec 2009 11:41:23 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Difference between "$var" and $var?
Message-Id: <ddb028a5-6b02-4ab0-9d7f-23c3d9042baf@d10g2000yqh.googlegroups.com>
On Dec 18, 11:42=A0am, sharma...@hotmail.com wrote:
> Is there any advantage in the assignment operation
> =A0 $dest =3D "$src" over
> =A0 $dest =3D $src =A0 =A0?
I don't really have anything new to add (that hasn't been already
stated by other posters), but I thought I might mention the following
perldoc FAQ:
perldoc -q "always quoting"
What's wrong with always quoting "$vars"?
Cheers,
-- Jean-Luc
------------------------------
Date: Fri, 18 Dec 2009 14:42:37 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Difference between "$var" and $var?
Message-Id: <874onoxe4y.fsf@quad.sysarch.com>
>>>>> "sr" == sharma r <sharma__r@hotmail.com> writes:
sr> On Dec 19, 12:14 am, "Uri Guttman" <u...@StemSystems.com> wrote:
>> >>>>> "sr" == sharma r <sharma...@hotmail.com> writes:
>>
>> sr> Hi,
>> sr> Is there any advantage in the assignment operation
>> sr> $dest = "$src" over
>> sr> $dest = $src ?
>>
>> this has been covered many times here in particular by tad. the "$src"
>> is not good in general. it makes an unneeded extra copy of the value. it
>> also can be a bug in that it stringifies the value and since it is a
>> copy, if a sub wanted to modify it in place, it would fail. the rule is
>> not to quote single scalar variables unless you really want a copy.
>>
>> sr> And then, are the following operations identical?
>> sr> $dest = "$varA:$varB:$varC";
>> sr> $dest = join ":", $varA, $varB, $varC;
>>
>> did you compare the results? did you see any differences? make up your
>> own mind about that.
sr> I didnt see any difference in "$var" & $var. So does that mean there's
sr> no difference?
please read what i said. i said check the difference in the $dest
things. my comments on "$src" were above that. i didn't say the same
things about both questions.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 18 Dec 2009 14:43:17 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Difference between "$var" and $var?
Message-Id: <87zl5gvzje.fsf@quad.sysarch.com>
>>>>> "JB" == John Bokma <john@castleamber.com> writes:
JB> "Uri Guttman" <uri@StemSystems.com> writes:
>> did you compare the results? did you see any differences? make up your
>> own mind about that.
JB> I think that's a bit unfair. I mean, you *don't* have to post a reply.
no, i wanted to really know if he actually compared the output. he was
asking almost as if he didn't know.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 18 Dec 2009 17:23:40 +0000
From: Justin C <justin.0912@purestblue.com>
Subject: Re: FAQ 8.21 Where do I get the include files to do ioctl() or syscall()?
Message-Id: <sdqsv6-top.ln1@purestblue.com>
In article <pViWm.75424$We2.8162@newsfe09.iad>, PerlFAQ Server wrote:
> 8.21: Where do I get the include files to do ioctl() or syscall()?
>
> Historically, these would be generated by the h2ph tool, part of the
> standard perl distribution. This program converts cpp(1) directives in C
> header files to files containing subroutine definitions, like
> &SYS_getitimer, which you can use as arguments to your functions. It
> doesn't work perfectly, but it usually gets most of the job done. Simple
> files like errno.h, syscall.h, and socket.h were fine, but the hard ones
> like ioctl.h nearly always need to hand-edited.
I know you're busy, but there's a grammatical error in that last
sentance. It would better read "...always need to _be_ hand-edited." or
"...always need editing by hand."
Thanks for maintaining these for us.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 18 Dec 2009 02:19:22 +0100
From: Josef <e9427749@stud4.tuwien.ac.at>
Subject: Re: Opening a file with case-insensitive name
Message-Id: <4b2b976a$0$12642$3b214f66@tunews.univie.ac.at>
Am 17.12.2009 08:36, schrieb John W. Krahn:
> Martijn Lievaart wrote:
>> On Wed, 16 Dec 2009 19:15:11 -0800, Jason Carlton wrote:
>>
>>> […] The question is, what if the file name is "MyFile.txt", but they type
>>> "myfile.txt", "MYFILE.TXT", "mYfILE.txt", or something similar. Is there
>>> a way to open the file and ignore the case of the file name? […]
> my @realfilenames = grep lc eq lc "/home/mydomain/$filename", glob
> '/home/mydomain/*';
Better
my $filename='bLaBlA.Txt';
(my $filepat=$filename) =~
s{(.)}
{ local $_=$1;
(uc ne lc) ? "[\U$_\L$_]" :
/[[\]{}\s]/ ? "\\$_" : $_ # or /[[\]{}\s*?]/
}ge;
my @filematches=glob($filepat);
my $mostlikely=exists $filematches[0] ? $filematches[0] : undef;
print join(',',@filematches)." from $filepat\n"
# BlaBla.txt from [Bb][Ll][Aa][Bb][Ll][Aa].[Tt][Xx][Tt]
The wildcards * and ? are allowed for the user.
If this is not desirable, than this chars can be added to the inner RE.
I expect that this solution is faster as the previous.
Another solution was presented from Jürgen (hash as cache).
His solution needs IHMO more time at startup for building the hash,
but the following searches should be faster.
Just guessing.
best regards & sorry for my bad english,
Josef
------------------------------
Date: Fri, 18 Dec 2009 06:19:20 -0800 (PST)
From: gorjusborg <brandon.n.atkinson@gmail.com>
Subject: Re: WWW::Mechanize
Message-Id: <5e31ed2c-893e-4024-a846-39d119260a10@j14g2000yqm.googlegroups.com>
I'm no Mech expert, but.. it is a pretty popular module.
You aren't wasting your time learning how to use it.
So 'perldoc WWW::Mechanize' is your friend...
That said....
Here's one way to choose a radio field value:
# (obviously not production code)
#
$mech->get("http://www.google.com");
$mech->form_number(1);
$mech->field('radiogroup_name', 'value you want to set');
$mech->click_button(number =3D> 1);
This assumes you know the radio name, and that the form is the first
one in the page, as well as the submit button being the first button
in the form. That's a lot of assumptions, but assumptions keep code
simple! If you need a more general solution, you'll have to do more
inspection by accessing data objects through Mech.
Mech scripts can get prohibitively complicated if you don't know
anything about the HTML you may encounter.
.
On Dec 18, 3:01=A0am, Nathan <nathan...@gmail.com> wrote:
> Hi,
> is anyone familiar with this module?
> I have a form with a radio button, any idea how do I click on it???
>
> to be more precise,I have an HTML page, with a radio button, and a
> submit button, how do I click / set the radio button??? (I managed to
> click the submit button...)
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 2730
***************************************
