[31688] in Perl-Users-Digest
Perl-Users Digest, Issue: 2951 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 19 00:09:25 2010
Date: Tue, 18 May 2010 21:09:08 -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 Tue, 18 May 2010 Volume: 11 Number: 2951
Today's topics:
bit-twiddling on 32-bit machines <here@softcom.net>
Re: bit-twiddling on 32-bit machines <ben@morrow.me.uk>
Re: bit-twiddling on 32-bit machines <here@softcom.net>
Re: bit-twiddling on 32-bit machines <ben@morrow.me.uk>
Re: determining whether a server supports secure authen <merrilljensen@q.com>
Re: determining whether a server supports secure authen <merrilljensen@q.com>
Re: determining whether a server supports secure authen <tadmc@seesig.invalid>
Re: Don't understand: when('foo' and/or 'bar') <uri@StemSystems.com>
Re: Don't understand: when('foo' and/or 'bar') sln@netherlands.com
Re: Don't understand: when('foo' and/or 'bar') <willem@turtle.stack.nl>
Re: Don't understand: when('foo' and/or 'bar') <derykus@gmail.com>
Re: Don't understand: when('foo' and/or 'bar') <uri@StemSystems.com>
Re: Don't understand: when('foo' and/or 'bar') <nospam-abuse@ilyaz.org>
Re: Don't understand: when('foo' and/or 'bar') <uri@StemSystems.com>
Re: MinGW and Perl 5.12 - Windows 64 bits ActiveState <rvtol+usenet@xs4all.nl>
Validate $q->param() instead of copying to hash first? <abc@def.com>
Re: WAB ftp Server <tim@johnsons-web.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 18 May 2010 13:18:16 -0700 (PDT)
From: Sal <here@softcom.net>
Subject: bit-twiddling on 32-bit machines
Message-Id: <19e8812a-7a12-46d0-a2d8-07111b7ae5b4@e34g2000pra.googlegroups.com>
I recently implemented a C hashing algorithm in Perl and wasted about
8 hours of my time trying to debug it because of a stupid assumption
on my part. When doing a lot of shifts and bit-wise xor's it's easy
for 32-bit integers to overflow into double precision floating point
values. I recognized this early on and thought I was capturing only
the lowest 32 bits with ($x &= 0xffffffff). That simply does not work!
The way I got around it was with ($x %= 4294967296). In hindsight it's
easy for me now to recognize why the first not only doesn't work but
doesn't even make sense with the mixed number types. I hope this helps
someone else. Happy bit-twiddling!
------------------------------
Date: Tue, 18 May 2010 21:57:59 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <njbbc7-6ks2.ln1@osiris.mauzo.dyndns.org>
Quoth Sal <here@softcom.net>:
> I recently implemented a C hashing algorithm in Perl and wasted about
> 8 hours of my time trying to debug it because of a stupid assumption
> on my part. When doing a lot of shifts and bit-wise xor's it's easy
> for 32-bit integers to overflow into double precision floating point
> values. I recognized this early on and thought I was capturing only
> the lowest 32 bits with ($x &= 0xffffffff). That simply does not work!
> The way I got around it was with ($x %= 4294967296). In hindsight it's
> easy for me now to recognize why the first not only doesn't work but
> doesn't even make sense with the mixed number types. I hope this helps
> someone else. Happy bit-twiddling!
perldoc -f integer
Ben
------------------------------
Date: Tue, 18 May 2010 14:21:37 -0700 (PDT)
From: Sal <here@softcom.net>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <7d2e69e4-8d71-4a43-9bea-222801809229@u3g2000prl.googlegroups.com>
On May 18, 1:57=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Sal <h...@softcom.net>:
>
> > I recently implemented a C hashing algorithm in Perl and wasted about
> > 8 hours of my time trying to debug it because of a stupid assumption
> > on my part. When doing a lot of shifts and bit-wise xor's it's easy
> > for 32-bit integers to overflow into double precision floating point
> > values. I recognized this early on and thought I was capturing only
> > the lowest 32 bits with ($x &=3D 0xffffffff). That simply does not work=
!
> > The way I got around it was with ($x %=3D 4294967296). In hindsight it'=
s
> > easy for me now to recognize why the first not only doesn't work but
> > doesn't even make sense with the mixed number types. I hope this helps
> > someone else. Happy bit-twiddling!
>
> perldoc -f integer
>
> Ben
Tried it, didn't work with the integer pragma. The only way I could
get it to work properly was to allow an integer promotion to a C
double and then do the modulo arithmetic to capture the least-
significant 32 bits.
------------------------------
Date: Wed, 19 May 2010 00:49:33 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <dllbc7-k0u2.ln1@osiris.mauzo.dyndns.org>
Quoth Sal <here@softcom.net>:
> On May 18, 1:57 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth Sal <h...@softcom.net>:
> >
> > > I recently implemented a C hashing algorithm in Perl and wasted about
> > > 8 hours of my time trying to debug it because of a stupid assumption
> > > on my part. When doing a lot of shifts and bit-wise xor's it's easy
> > > for 32-bit integers to overflow into double precision floating point
> > > values. I recognized this early on and thought I was capturing only
> > > the lowest 32 bits with ($x &= 0xffffffff). That simply does not work!
> > > The way I got around it was with ($x %= 4294967296). In hindsight it's
> > > easy for me now to recognize why the first not only doesn't work but
> > > doesn't even make sense with the mixed number types. I hope this helps
> > > someone else. Happy bit-twiddling!
> >
> > perldoc -f integer
>
> Tried it, didn't work with the integer pragma. The only way I could
> get it to work properly was to allow an integer promotion to a C
> double and then do the modulo arithmetic to capture the least-
> significant 32 bits.
Depending on what you're doing, promotion to double *should* safely give
you 53 bits of integer precision, but you may want to consider
rebuilding your perl with -Duse64bitint to avoid type conversion all
over the place. The standard FreeBSD build has been built with this
option for a while now, and there is some talk of using it for the
Debian builds of 5.12.
Ben
------------------------------
Date: Tue, 18 May 2010 19:34:34 -0600
From: Uno <merrilljensen@q.com>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <85gthbFuikU1@mid.individual.net>
Peter J. Holzer wrote:
> On 2010-05-16 23:08, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>> On 2010-05-16, Uno <merrilljensen@q.com> wrote:
>>> I was "sure" that I was using SSL, and in my head it sounded right that
>>> a secure socket layer would employ secure authentication. They are
>>> completely separate notions.
>> Secure connection makes absolutely no sense without secure
>> authentication
>
> I admit that I don't know exactly what "secure authentication" in SMTP
> context means (haven't found a spec yet and I'm too lazy to read
> Thunderbird source code (besides, it's written in C++ and off-topic in
> this group :-) )) but I do know that it is some microsoft-proprietary
> authentication mechanism and probably has something to do with a domain
> controller. Surely you don't think thet SSL doesn't make sense unless
> you can authenticate against a Windows domain controller, do you?
Peter,
I think this link will help:
http://www.kuro5hin.org/?op=displaystory;sid=2002/4/28/1436/66154
>
> If you use STARTTLS (or SSMTP), the authentication will be part of the
> encrypted session and safe from eavesdropping (including MITM attacks in
> a typical SUBMISSION scenario), so even PLAIN authentication is
> moderately safe. CRAM-MD5 trades one weakness for another (instead of
> sending a plain text passwort over an encrypted channel it is now stored
> unencrypted on the server). Client-Certificates would be best but aren't
> common, AFAIK.
>
>
>> The standard analogy of secure connection is sending a parcel guarded
>> by a policeman on route. The standard analogy of having no secure
>> authentication is leaving a package on a bench in a public park so
>> that the other party may come and pick it up. Now imagine doing
>> both...
>
> I don't think you analogy has much to do with the situation.
We can dispense with the analogies:
> How Authentication Works
>
> The NTLM authentication process uses the following algorithm:
>
> 1. Client sends NTLM Authentication Request to the server.
> 2. Server sends a 64-bit NTLM challenge to the client.
> 3. Client uses the challenge and an NTLM password hash to create an NTLM response.
> 4. The client sends the NTLM response to the server.
> 5. The server creates an NTLM response (since it also has your NTLM password hash) and compares its version with the one received by the client.
> 6. If the responses match, the authentication is successful.
I guess I don't know who an "attacker" is. I see movies where any
computer capability can exist, like Seth Green controlling traffic in
Los Angeles in "The Italian Job." I admire Seth's genius (Robot
Chicken), but don't think the situation possible.
What would it take for another entity to suck up all my packets that I
sent to q.com?
--
Uno
------------------------------
Date: Tue, 18 May 2010 19:53:53 -0600
From: Uno <merrilljensen@q.com>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <85gulhF481U1@mid.individual.net>
Peter J. Holzer wrote:
>> Can I use the perl programming language to determine whether what type
>> of authentication this server understands?
>
> Yes. However, you don't have to write that program yourself, as somebody
> has already done it: Look for "swaks" (the SWiss Army Knife for Smtp).
> Some linux distributions (e.g. Debian) include it, or you can download
> it from http://www.jetmore.org/john/code/swaks/
I appreciate the forbearance of this forum not to say "there's no perl
here" before I could get a handle on this well enough to do it with
perl, at least partially. I'm going on six months of studying unix,
which I find very consonant with studying perl syntax.
So this is what I have:
$ ./smtp1.pl
220 BLU0-SMTP57.blu0.hotmail.com Microsoft ESMTP MAIL Service, Version:
6.0.3790.4675 ready at Tue, 18 May 2010 17:27:46 -0700
$ cat smtp1.pl
#!/usr/bin/perl
use IO::Socket;
use strict;
use warnings;
my $remote_host = "smtp.live.com";
my $remote_port = "25";
my $socket = new IO::Socket::INET (PeerAddr => $remote_host,
PeerPort => $remote_port,
Proto => "tcp",
Type => SOCK_STREAM)
or die "scheisse mal\n";
print $socket "data\n";
my $line = <$socket>;
print $line;
$
q1) Can someone say a few words about the differences between the print
statements. Apparently, one sends a message to another machine, and the
other sends a message to mine.
q2) I poked around for an example listing for Programming Perl, 3rd
Edition and could not find one. Does anyone know where I might get an
electronic subset of the book I bought? Keystrokes are expensive for my
hands.
Cheers,
--
Uno
------------------------------
Date: Tue, 18 May 2010 21:34:34 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <slrnhv6j7s.k8p.tadmc@tadbox.sbcglobal.net>
Uno <merrilljensen@q.com> wrote:
> my $socket = new IO::Socket::INET (PeerAddr => $remote_host,
> PeerPort => $remote_port,
> Proto => "tcp",
> Type => SOCK_STREAM)
> or die "scheisse mal\n";
>
> print $socket "data\n";
This one is:
print FILEHANDLE LIST
> my $line = <$socket>;
>
> print $line;
This one is:
print LIST
> q1) Can someone say a few words about the differences between the print
> statements.
perldoc -f print
> Apparently, one sends a message to another machine,
FILEHANDLE may be a scalar variable name, in which case the variable
contains the name of or a reference to the filehandle
> and the
> other sends a message to mine.
If FILEHANDLE is omitted, prints by default to standard output
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Tue, 18 May 2010 14:25:35 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <87k4r1f4o0.fsf@quad.sysarch.com>
>>>>> "WH" == Wolfram Humann <w.c.humann@arcor.de> writes:
WH> On 18 Mai, 18:54, Willem <wil...@turtle.stack.nl> wrote:
>> print('foo' and 'bar'); # bar
>> print('foo' or 'bar'); # foo
>>
>> I guess the smart matching doesn't distribute ofer the 'and' or the 'or'.
>>
WH> Hm, sounds reasonable. However, it's not really what I expected from
WH> the explanation for "when(EXPR)" in perlsyn:
WH> Furthermore:
WH> If EXPR is ... && ... or ... and ..., the test is applied
WH> recursively to both arguments. If both arguments pass the test, then
WH> the argument is treated as boolean.
WH> If EXPR is ... || ... or ... or ..., the test is applied
WH> recursively to the first argument.
WH> These rules look complicated, but usually they will do what you
WH> want.
having read the docs i agree it isn't very clear. try it again with
regexes like /foo/ and /bar/ also with && instead of 'and'. i feel the
logic as the docs seem to say is $_ ~~ EXPR which makes it:
$_ ~~ 'foo' and 'bar'
that evaluates to
($_ ~~ 'foo') and 'bar'
so it won't distribute as you think (and the docs seem to imply). this
could be a bug in perl or the docs. i would raise the issue on p5p as
this definitely seems ambiguous.
also try explicit tests like $_ eq 'foo' which should work.
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: Tue, 18 May 2010 11:32:33 -0700
From: sln@netherlands.com
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <55n5v5pkdhial5dps6qg2r2rljj5umking@4ax.com>
On Tue, 18 May 2010 11:06:34 -0700 (PDT), Wolfram Humann <w.c.humann@arcor.de> wrote:
>On 18 Mai, 18:54, Willem <wil...@turtle.stack.nl> wrote:
>> print('foo' and 'bar'); # bar
>> print('foo' or 'bar'); # foo
>>
>> I guess the smart matching doesn't distribute ofer the 'and' or the 'or'.
>>
>
>Hm, sounds reasonable. However, it's not really what I expected from
>the explanation for "when(EXPR)" in perlsyn:
> Furthermore:
> If EXPR is ... && ... or ... and ..., the test is applied
>recursively to both arguments. If both arguments pass the test, then
>the argument is treated as boolean.
> If EXPR is ... || ... or ... or ..., the test is applied
>recursively to the first argument.
> These rules look complicated, but usually they will do what you
>want.
>
>As a matter of fact, if the 'and' and 'or' are evaluated before the
>smart matching applies, IMHO it would be better to state exactly that
>instead of saying "usually they will do what you want" :-)
>Thanks for the reply,
>Wolfram
>
Hum, hows that old given/when thing worky for ya?
Recursive boolean expression, now where has that been all these years?
-sln
------------------------------
Date: Tue, 18 May 2010 18:35:01 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <slrnhv5nel.1l8r.willem@turtle.stack.nl>
Wolfram Humann wrote:
) On 18 Mai, 18:54, Willem <wil...@turtle.stack.nl> wrote:
)> print('foo' and 'bar'); ?# bar
)> print('foo' or 'bar'); ? # foo
)>
)> I guess the smart matching doesn't distribute ofer the 'and' or the 'or'.
)>
)
) Hm, sounds reasonable. However, it's not really what I expected from
) the explanation for "when(EXPR)" in perlsyn:
) Furthermore:
) If EXPR is ... && ... or ... and ..., the test is applied
) recursively to both arguments. If both arguments pass the test, then
) the argument is treated as boolean.
) If EXPR is ... || ... or ... or ..., the test is applied
) recursively to the first argument.
) These rules look complicated, but usually they will do what you
) want.
Perhaps you should read back and see what 'the test' is that they are
talking about (it's the test to see if smart matching applies or not).
In your case, the test doesn't apply, and smart matching is done.
Then you get ($_ ~~ ('foo' or 'bar')), which evaluates to ($_ ~~ 'foo')
) As a matter of fact, if the 'and' and 'or' are evaluated before the
) smart matching applies, IMHO it would be better to state exactly that
) instead of saying "usually they will do what you want" :-)
The bit you quoted doesn't have to do with that, it's just about deciding
when to apply smart matching or not. I guess a perl guru can give a more
detailed explanation on that.
Smart matching itself doesn't do anything special with &&, and, ||, or.
('bar' ~~ ('foo' or 'bar')) evaluates to 0.
However, to get the behaviour for 'or' that you want, you can do something
like: given($x) { when (['foo', 'bar']) { say 'f' } }
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Tue, 18 May 2010 13:29:28 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <5eb14226-f44c-4bc3-b051-3d78a4152ada@k17g2000pro.googlegroups.com>
On May 18, 9:54=A0am, Willem <wil...@turtle.stack.nl> wrote:
> Wolfram Humann wrote:
>
> ) Would someone be so kind to explain the following (quotes are for
> ) win32 perl):
> )
> ) perl -E" $u=3D'foo'; given($u){ when('foo' and 'bar'){say 'f'}
> ) default{say 'd'} } "
> ) d
> ) perl -E" $u=3D'bar'; given($u){ when('foo' and 'bar'){say 'f'}
> ) default{say 'd'} } "
> ) f
> ) perl -E" $u=3D'baz'; given($u){ when('foo' and 'bar'){say 'f'}
> ) default{say 'd'} } "
> ) d
> ) perl -E" $u=3D'foo'; given($u){ when('foo' or 'bar'){say 'f'}
> ) default{say 'd'} } "
> ) f
> ) perl -E" $u=3D'bar'; given($u){ when('foo' or 'bar'){say 'f'}
> ) default{say 'd'} } "
> ) d
> ) perl -E" $u=3D'baz'; given($u){ when('foo' or 'bar'){say 'f'}
> ) default{say 'd'} } "
> ) d
> ) My expectation was: smart matching of two strings uses 'eq'. $u can
> ) not be equal to both 'foo' and 'bar' at the same time so in the 'and'
> ) case I always expect the default 'd'. In the 'or' case I expect 'f' to
> ) be printed if $u is either 'foo' or 'bar'.
> ) Why is my expectation wrong?
>
> print('foo' and 'bar'); =A0# bar
> print('foo' or 'bar'); =A0 # foo
>
> I guess the smart matching doesn't distribute ofer the 'and' or the 'or'.
>
That seems to be the case:
perl -MO=3DDeparse -E"$u=3D'foo'; given($u){ when('foo' and 'bar'){say
'f'}
default{say 'd'} } "
BEGIN { ... }
$u =3D 'foo';
given ($u) {
when ('bar') {
say 'f';
}
default {
say 'd';
}
}
perl -MO=3DDeparse -E" $u=3D'bar'; given($u){ when('foo' or 'bar'){
say 'f'} default{ say 'd'} } "
BEGIN { ... }
$u =3D 'bar';
given ($u) {
when ('foo') {
say 'f';
}
default {
say 'd';
}
}
--
Charles DeRykus
------------------------------
Date: Tue, 18 May 2010 16:44:51 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <87hbm5c530.fsf@quad.sysarch.com>
>>>>> "CD" == C DeRykus <derykus@gmail.com> writes:
>> I guess the smart matching doesn't distribute ofer the 'and' or the 'or'.
CD> That seems to be the case:
CD> perl -MO=Deparse -E"$u='foo'; given($u){ when('foo' and 'bar'){say
CD> 'f'}
CD> default{say 'd'} } "
CD> BEGIN { ... }
CD> $u = 'foo';
CD> given ($u) {
CD> when ('bar') {
'foo' and 'bar' compile time reduce to 'bar'.
CD> say 'f';
CD> }
CD> default {
CD> say 'd';
CD> }
CD> }
CD> perl -MO=Deparse -E" $u='bar'; given($u){ when('foo' or 'bar'){
CD> say 'f'} default{ say 'd'} } "
CD> BEGIN { ... }
CD> $u = 'bar';
CD> given ($u) {
CD> when ('foo') {
'foo' or 'bar' compile time reduce to 'foo'.
CD> say 'f';
CD> }
CD> default {
CD> say 'd';
CD> }
CD> }
given (pun intended) that, i would say the docs are buggy in this
area. or at least ambiguous and should be fixed. the 'test' for type
inside the when seems to be for simple types and not complex
expressions. this makes some sense in that how would perl know which
smart match mode to use for each part of a complex boolean expression?
but the docs should explain that better as it does
In fact "when(EXPR)" is treated as an implicit smart match most
of the time. The exceptions are that when EXPR is:
so it isn't all the time that is does a smart match.
o If EXPR is "... && ..." or "... and ...", the test is applied
recursively to both arguments. If both arguments pass the test,
then the argument is treated as boolean.
that is poorly written IMO. it seems to mean (as we have learned) the
test for the TYPE is done on both boolean args. then this expression is
run just as a boolean (and that is why the deparse drops the second
boolean arg - it can't affect the boolean since the other arg is a
constant). but how would you ever implicitly invoke smart matching if
you have a boolean expression? the example in the docs shows:
when (/^\d+$/ && $_ < 75) { ... }
and that does not imply any smart matching. it is a regex against $_ and
a normal expression.
this does need some more explanation. i see a smart match tutorial in
the future (prolly not from me!).
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: Tue, 18 May 2010 23:19:13 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <slrnhv683h.5oh.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-18, Uri Guttman <uri@StemSystems.com> wrote:
> constant). but how would you ever implicitly invoke smart matching if
> you have a boolean expression? the example in the docs shows:
>
> when (/^\d+$/ && $_ < 75) { ... }
>
> and that does not imply any smart matching. it is a regex against $_ and
> a normal expression.
>
> this does need some more explanation. i see a smart match tutorial in
> the future (prolly not from me!).
I think the much more productive solution is to avoid smart matching
completely. (I have no idea WHY it was added to the language; looks
like a severely not-enough-thought-about feature...)
Yours,
Ilya
------------------------------
Date: Tue, 18 May 2010 21:14:00 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <871vd87kx3.fsf@quad.sysarch.com>
>>>>> "IZ" == Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
IZ> On 2010-05-18, Uri Guttman <uri@StemSystems.com> wrote:
>> constant). but how would you ever implicitly invoke smart matching if
>> you have a boolean expression? the example in the docs shows:
>>
>> when (/^\d+$/ && $_ < 75) { ... }
>>
>> and that does not imply any smart matching. it is a regex against $_ and
>> a normal expression.
>>
>> this does need some more explanation. i see a smart match tutorial in
>> the future (prolly not from me!).
IZ> I think the much more productive solution is to avoid smart matching
IZ> completely. (I have no idea WHY it was added to the language; looks
IZ> like a severely not-enough-thought-about feature...)
this isn't a smart matching issue but a when/given issue and when it
will use smart matching. if you want to bitch about a feature, then
know which is which before you bitch! :)
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: Tue, 18 May 2010 23:17:47 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: MinGW and Perl 5.12 - Windows 64 bits ActiveState
Message-Id: <4bf303fb$0$22940$e4fe514c@news.xs4all.nl>
sisyphus wrote:
> On May 17, 6:36 am, Ben Morrow <b...@morrow.me.uk> wrote:
>>> C:/Users/CK/DOCUME~1/PROGRA~2/MINGW6~1/gcc.exe -c -DNDEBUG -
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Is this a 'spaces in the path' or 'path too long' problem?
>
> I think this is just ActiveState's way of circumventing the 'spaces in
> the path' problem. They use Win32::GetShortPathName() to convert to
> the short pathname because that's guaranteed to contain no spaces.
> Having the compiler installed in that location shouldn't be causing
> any problems.
Good chance that "install the compiler somewhere like c:\mingw64", like
Ben proposed, will fix much.
--
Ruud
------------------------------
Date: Wed, 19 May 2010 02:28:54 +0100
From: zaphod <abc@def.com>
Subject: Validate $q->param() instead of copying to hash first?
Message-Id: <XtudnZIaMMdKo27WnZ2dnUVZ7rSdnZ2d@brightview.co.uk>
Although I'm using CGI::Application this also relates to the use of CGI.pm
I would like to know if there is any benefit in validating the $q->param() hash in place before copying it to a lexical hash. In other words, is it better to:
<do something> if $q->param(foo) !~ /<some regexp>/;
..... rather than:
$form_fields{$_} = $q->param($_) for $q->param();
<do something> if $form_fields{foo} !~ /<some regexp>/;
Is there a difference in security?
zaphod
------------------------------
Date: Tue, 18 May 2010 13:43:06 -0500
From: Tim Johnson <tim@johnsons-web.com>
Subject: Re: WAB ftp Server
Message-Id: <slrnhv5mlv.8kq.tim@bart.johnson.com>
On 2010-05-17, J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
>
> First, I'd suggest not wasting your time and contact the vendor.
> Possibly they (re)moved their FTP service to another machine.
The reason that I posted this article is because the vendor has been
extremely non-responsive. Worse, the vendor moderates their mailing
list and has declined to forward *any* email regarding these problems,
thus disabling the ability of the joint community to trouble-shoot
amongst themselves and as a side effect, help the vendor.
> To waste time, you could try command line arguments common to
> FTP, during the session, to see what's avaiable, e.g. ?.
?? :(
It is beginning to be apparent that the server, when properly
configured and correctly maintained is likely to support a standard
command set. Thus my original assumption and my reason for posting
was probably incorrect.
Thanks to you all (and especially to RedGrittyBrick for some good
tips which I will forward to my partner).
regards
--
Tim
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com
------------------------------
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 2951
***************************************
