[23171] in Perl-Users-Digest
Perl-Users Digest, Issue: 5392 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 19 21:05:47 2003
Date: Tue, 19 Aug 2003 18:05:06 -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, 19 Aug 2003 Volume: 10 Number: 5392
Today's topics:
Re: and why can't I do my own CGI? <scripts_you_know_the_drill_@hudsonscripting.com>
Re: and why can't I do my own CGI? <scripts_you_know_the_drill_@hudsonscripting.com>
Re: and why can't I do my own CGI? <scripts_you_know_the_drill_@hudsonscripting.com>
Re: CGI is not so hard <scripts_you_know_the_drill_@hudsonscripting.com>
Re: comp.lang.perl.zombie rfc in alt.config <scripts_you_know_the_drill_@hudsonscripting.com>
Re: FrontPage and perl (John M. Gamble)
Re: hand crafting soap for google api's <scripts_you_know_the_drill_@hudsonscripting.com>
Re: how to rename 200 files in many sub-directories? <geoff.cox@blueyonder.co.uk>
Re: Low-level way of fetching UDP datagram as a unit <ben.goldberg@hotpop.com>
Messages from FreezeThaw of a DBI handle <wwonko@rdwarf.com>
Re: Module::Build is yet more broken... (Sam Holden)
Re: Order of evaluation of expressions <krahnj@acm.org>
Re: Perl or PHP for web work ? <matt+nntp@askmenoquestions.co.uk>
Re: Perl or PHP for web work ? <damian@phpexpert.org>
Re: Problem with FindBin and taint mode under Windows <wwonko@rdwarf.com>
Re: Send Message over UNIX Socket <ben.goldberg@hotpop.com>
sub param in CGI.pm <scripts_you_know_the_drill_@hudsonscripting.com>
Re: sub param in CGI.pm <scripts_you_know_the_drill_@hudsonscripting.com>
Re: sub param in CGI.pm <kkeller-spammmm@wombat.san-francisco.ca.us>
Re: sub param in CGI.pm <scripts_you_know_the_drill_@hudsonscripting.com>
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Aug 2003 20:42:35 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: and why can't I do my own CGI?
Message-Id: <oer5kvgfnhdfcc4tcjd8615u6qtc7l0jot@4ax.com>
Thanks Tassilo,
I just read several books about unix and C and I am amazed at how much
it helped me understand Perl, so I totally agree with you.
------------------------------
Date: Tue, 19 Aug 2003 20:44:09 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: and why can't I do my own CGI?
Message-Id: <ajr5kvok5677p9qt2thaoan8ee7e1hu35m@4ax.com>
Thanks Jonathan,
I took your advice and started looking at the CGI.pm ;-)
------------------------------
Date: Tue, 19 Aug 2003 20:45:28 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: and why can't I do my own CGI?
Message-Id: <flr5kv0dplpspi82kdnv4n5besd4qm7sve@4ax.com>
>One issue you didn't mention, which seems to me to be very relevant in
>practice: even the simplest of hand-coded scripts has a tendency to
>add features during its life. Maybe to support POST when it was
>originally only to support GET - maybe to support file-upload when it
>originally didn't - maybe to support re-writing an incomplete form and
>prompting for required fields that had been left blank or wrongly
>completed - and so on. If started off the right way, then CGI.pm
>allows such features to be bolted on almost for free. If started off
>with hand-coding, then such a script rapidly becomes an insecure and
>unmaintainable quivering heap. I know - I've made just that mistake
>for myself, in the early days.
this was a great post for me, since I can really relate to it ;-)
------------------------------
Date: Tue, 19 Aug 2003 20:28:19 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: CGI is not so hard
Message-Id: <0gq5kvoirv7mfuoqa727t16if7erqtke6l@4ax.com>
On Sun, 17 Aug 2003 22:42:58 -0500, "William Alexander Segraves"
<wsegrave@mindspring.com> wrote:
>Failing to deal with $key in similar fashion (to what is done for $value) is
>a common mistake committed
>by beginners, e.g., your parsing scheme wouldn't work well with any instance
>of the submittal of
>
> 'a key like this';
>
>because it would leave it in the form
>
> 'a+key+like+this'
Hi Bill,
I didn't deal with $key because I checked for a match for $key and I
wrote the html form. If a key is unexpected, it won't match, so there
are no worries:
my @form_variables= qw(variables_1
variables_2
etc
);
and later:
for my $variables (@form_varibles) {
if ($key eq "$varible") {
$kv{$key} = $value;
}
}
------------------------------
Date: Tue, 19 Aug 2003 20:11:46 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: comp.lang.perl.zombie rfc in alt.config
Message-Id: <cjp5kvsf0cj4vluv72ju9fk8juvj2v7vt6@4ax.com>
>Now would be a good time to claim that someone else is posting under your name
>to make you appear a complete twat. Or perhaps that Engligh is not your native
>language.
>
>Leave the newsgroup alone for a week or two and then come back.
OK...surely I was posting while intoxicated....the #1 bad thing to do
on usenet...so, no...it wasn't me, I'm taking a nice long vacation
from my computer, and when I return I will probably be posting under
the name Mississippi or something.
And.......I never realized alt.config was only for alt newsgroups ;-)
------------------------------
Date: Tue, 19 Aug 2003 23:04:47 +0000 (UTC)
From: jgamble@ripco.com (John M. Gamble)
Subject: Re: FrontPage and perl
Message-Id: <bhuaef$j9e$1@e250.ripco.com>
In article <2edd058c.0308132347.10085e7d@posting.google.com>,
gnarred <gnarred@yahoo.com> wrote:
>jgamble@ripco.com (John M. Gamble) wrote in message
>news:<bhe1rh$k0p$1@e250.ripco.com>...
>> Are there any known "gotchas" when developing with FrontPage
>> and perl? The ISP provides perl for the server side, and my
>> friend's husband is very insistent about using FrontPage for
>> designing the website.
>>
>> It's not my first choice, but i'm willing to go along. So...
>>
>> Anything i should look out for (excluding the usual MS-bashing)?
>> This will be my first foray into FrontPage.
>
>I've worked on a large web site maintained via Frontpage and I can
>tell you this: if you edit and upload files apart from Frontpage you
>will eventually run into problems. If you're going to use Frontpage as
>your HTML editor be sure you don't edit & upload too many files with a
>different editor or FTP program (or, alter Frontpage-generated files
>with a Perl CGI). Frontpage may also delete files that aren't in the
>web it's trying to upload, so be careful.
>
Thanks, i'll look out for that. I take it from your description that
FrontPage maintains a list of what's "supposed" to be there, and gets
confused if there's extra materials?
--
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
------------------------------
Date: Tue, 19 Aug 2003 19:38:15 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: hand crafting soap for google api's
Message-Id: <nmn5kv03fqf2gcmd6pqpdi1j8872ts6qo6@4ax.com>
>Perfectly correct: but you're aiming to implement a general-purpose
>script (as any self-respecting professional would do), whereas the
>kiddie is trying to write a partial implementation, thinking that
>it'll be as much as they'd need for the present, and ignoring that
>many related tasks will arise later and need the script expanding in
>various ways.
"kiddie"
>> from http://www.w3.org/TR/REC-html32
>
>Oh, c'mon, you don't seriously think Abigail doesn't know all this;
>and if you're of a mind to quote specifications, then let's have a
>decent one, not that fly-blown old carcass of HTML3.2 (spit).
>
>> so supporting duplicate names is required
>
>If you're a professional - of course it is.
>
>> any cgi parser that doesn't do that is broken or a toy or only for play
>> by the author.
>
>Well, that's what we have been dealing with all along on this thread,
>as if you hadn't already noticed ;-)
hmmm
>Now please, let's stop baiting the would-be troll, and get on with
>something more productive.
now...just who is baiting who ;-)
------------------------------
Date: Tue, 19 Aug 2003 23:17:52 +0100
From: Geoff Cox <geoff.cox@blueyonder.co.uk>
Subject: Re: how to rename 200 files in many sub-directories?
Message-Id: <1a85kvc426vgkf5sh9jfm1c9oitqrbqcm4@4ax.com>
On Tue, 19 Aug 2003 00:51:01 GMT, "John W. Krahn" <krahnj@acm.org>
wrote:
>Geoff Cox wrote:
>>
>> On Mon, 18 Aug 2003 10:25:57 GMT, "John W. Krahn" <krahnj@acm.org>
>> wrote:
>>
>> John,
>>
>> I wonder if you could just explain what is happening in the sub ..?
>
>Sure, it's not that complicated. :-)
Many thanks John - very helpful.
You might like to know that I gave this assistance of yourself and the
others as an example of the better side to the Internet, tonight, at a
talk I gave at our local Computer Club!
Cheers
Geoff
>
>
>> >use warnings;
>> >use strict;
>> >
>> >use File::Find;
>> >use Archive::Zip;
>> >
>> >my $dir = 'c:/docs';
>> >
>> >find( sub {
>> > ( my $name = $_ ) =~ s/\.zip$/.doc/i or return;
>
>$_ contains the name of the current file which is assigned to $name. A
>substitution is performed on $name and if it ends with the four
>characters '.zip' (or '.ZIP' or '.Zip', etc.) they are replaced with the
>four characters '.doc'. If the substitution was not successful (the
>file name didn't end in '.zip') return from the sub. If successful $_
>will contain 'somefile.zip' and $name will contain 'somefile.doc'.
>
>
>> > my $zip = Archive::Zip->new( $_ );
>
>Create an Archive::Zip object using the file name in $_.
>
>
>> > $zip->extractMember( ($zip->memberNames)[ 0 ], $name );
>
>Use $zip->memberNames to get the first file name from the zip archive
>and use $zip->extractMember to store the contents of that file using the
>file name in $name.
>
>
>> > unlink $_ or warn "Cannot delete $_: $!";
>
>Delete (unlink) the file $_ or complain if you can't.
>
>
>> > }, $dir );
>
>Use the directory name in $dir as the starting point in the search.
>
>
>
>John
------------------------------
Date: Tue, 19 Aug 2003 20:33:42 -0400
From: Benjamin Goldberg <ben.goldberg@hotpop.com>
Subject: Re: Low-level way of fetching UDP datagram as a unit
Message-Id: <3F42C1E6.652053BC@hotpop.com>
John Ramsden wrote:
>
> I am writing an SNMP trap handler, using Graham Barr's Convert::BER
> module (which looks excellent, from what I can see) to translate the
> PDUs from binary to a manageable structure.
>
> When reading raw traps from a socket connection, Convert::BER relies
> on the datagram length which appears near the start of the raw trap
> string.
>
> But, as Barr points out in a source code comment, what is to stop a
> hacker (or just an erroneous program) sending to an SNMP trap port
> an SNMP trap datagram with a length longer than tha actual length
> of the datagram, thus causing the trap handler to hang while it
> waits for the rest of the datagram which may never appear?
I don't know anything about SNMP, so this is off the top of my head...
A udp datagram arrives in full, or not at all. Thus, "wait for the rest
of the datagram" doesn't make sense, if it's referring to a udp
datagram.
Thus, you must mean, "waits for the rest of the PDU," which I assume is
allowed to consist of multiple UDP packets.
UDP is an *unreliable* datagram protocol. So, it's quite possible that
even in normal operation (not involving evil hackers, or erroneous
programs), one or more UDPs get lost (or rearranged). One would hope
that SNMP specifies how to deal with getting a UDP packet which starts a
PDU, but losing the rest of the PDU.
Whatever one does in *that* situation, also applies to an evil hacker,
or an erroneous program, sending you a bad packet.
> Anyway, apart from using a timeout, I was wondering if there is some
> lower-level Perl (or any) method of reading an UDP datagrams as a
> unit, so that this problem cannot arise.
Use the recv() system call, and you'll get a UDP datagram as a unit.
What in the world are you using which might possibly give you only part
of a UDP datagram?
> Also, I need solutions for Unix and Windows if possible, even if a
> different approach must be used for each.
If Windows implements udp, then you'll have the recv system call.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
------------------------------
Date: Tue, 19 Aug 2003 23:14:19 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Messages from FreezeThaw of a DBI handle
Message-Id: <bhub0b$taa$1@holly.rdwarf.com>
Our news server wasn't letting messages get out when I wrote this,
and I thought it might help someone else who had this problem, so I'm
reposting it.
I hope it's helpful.
Louis Erickson <wwonko@rdwarf.com> wrote:
: Digging around, I found several comments about this on the 'net, but didn't
: find a really conclusive discovery of what caused it, and thought I'd share
: what I found with the group, and with the archives.
: Forgive me if this is common knowledge. It was filling up my Apache logs,
: and I had to fiddle with it for a couple of hours to find it, and I thought
: maybe I'd save someone the time. =)
: If you FreezeThaw a database handle from DBI, then you'll get some strange
: errors to STDOUT when you thaw it. They look like this:
: SV = RV(0x879ced0) at 0xbffff710
: REFCNT = 1
: FLAGS = (ROK,READONLY)
: RV = 0x87a3ea4
: I don't know what generates them or why, but if you don't thaw the database
: handle, they don't occur.
: My workaround was to remove the database handle from the hash I was freezing,
: and put it back after I had done so. That way, it wasn't there when I tried
: to thaw it.
: This seemed to affect both Linux with Perl 5.6.0 and Windows with ActiveState
: Perl 5.6.1.
: Hope it helps someone, and if someone knows a better solution, I'd be happy
: to hear it!
: Thanks!
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
An effective way to deal with predators is to taste terrible.
------------------------------
Date: 20 Aug 2003 00:40:01 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: Module::Build is yet more broken...
Message-Id: <slrnbk5gr0.d2f.sholden@flexal.cs.usyd.edu.au>
On Tue, 19 Aug 2003 15:53:06 +0000 (UTC),
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to
> Sam Holden
><sholden@cs.usyd.edu.au>], who wrote in article <slrnbk2j1t.dl5.sholden@flexal.cs.usyd.edu.au>:
>> > Why do you think so? `perl Build' being different from `perl
>> > Build.PL' - this depends on the (undocumented and quite probably
>> > subject to change soon) order of executable extensions for the Perl
>> > scripts. Moreover, who guaranties that there is no F<Build> on the
>> > PATH before '.'?
>>
>> I'm saying that if the module works so that executing Build.PL
>> creates a perl script called Build in the current directory (which is
>> implied by the "./Build test" command you mentioned) then after running
>> perl Build.PL you can just run "perl Build test" instead of "./Build test".
>
> What I was saying was that this is wrong. Why do you think that given
> both `Build' and `Build.PL' in the current directory the command `perl
> Build' will prefer running `Build' vs. running Build.PL?
Simply because I can't see any reason why perl would want to do otherwise.
If there are such systems then replace "Build.PL" with "Setup.PL" and
"Build" with "Build.PL" or whatever. The actual names of the files
are pretty much irrelevant to me.
If there is no platform independant way of specifying run the perl
script "foo" and pass it the argument "bar", then I guess some sort
of english description (better than mine, hopefully) would need to
be used.
If there are a handful of wierdo architectures that are completely
different then examples of those can be used along with the
general case.
If you have no problem with "perl Makefile.PL" as instructions
then I can't see how some name other than "Makefile" can be
a problem.
>> The command "perl Build test" tells perl to run the script in the file
>> "Build" in the current working directory and set @ARGV to be ('test').
>
>> Is there *any* platform on which this is not true?
>
> You mean "currently" or "in foreseeable future"? I would not vouch in
> the second case...
Why would that ever change? perl5.8.0 still accepts ' as a package
seperator, why would backwards compatibility be broken so badly for
absolutely no gain whatsoever (as far as I can tell).
I can't see any benefit of an operating system automatically fudging command
line arguments in order to break programs which accept arguments that happen
to also be commands existing elsewhere.
And if it does happen then the current "perl Makefile.PL" used by the
existing system isn't going to work anymore either - so that seems a bit
irrelevant when discussing the relative merits of the two approaches.
--
Sam Holden
------------------------------
Date: Wed, 20 Aug 2003 00:12:11 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: Order of evaluation of expressions
Message-Id: <3F42BCBC.276477FC@acm.org>
Abigail wrote:
>
> John W. Krahn (krahnj@acm.org) wrote on MMMDCXL September MCMXCIII in
> <URL:news:3F417BDC.7F24A9F3@acm.org>:
> ==
> == Just going by perlop.pod, shift() is a named unary operator which has
> == lower precedence than . and . is left associative which would mean it
> == would evaluate the left side first. Correct me if I'm wrong. :-)
>
> Precedence isn't the same as order of evaluation.
Yes I know. What I was trying to say is that the concatenation operator
is left associative so that:
shift(@a) . shift(@b) . shift(@c) . shift(@d)
will be always be evaluated as:
( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
unless you explicitly parenthesise the expression. So it should follow
that if shift(@a) . shift(@b) . shift(@c) is always evaluated before
shift(@d) and shift(@a) . shift(@b) is always evaluated before
shift(@c), shouldn't it follow that shift(@a) is evaluated before
shift(@b)?
John
--
use Perl;
program
fulfillment
------------------------------
Date: Tue, 19 Aug 2003 23:32:53 +0000
From: matty <matt+nntp@askmenoquestions.co.uk>
Subject: Re: Perl or PHP for web work ?
Message-Id: <9Gx0b.9315$z7.1117530@wards.force9.net>
James wrote:
>>
>>Use PHP. PHP was designed for the web and Perl, for all its
>>flexibility and power, was not.
>>
>>Besides, for your purposes there really isn't anything that Perl
>>can do that PHP can't do equally as well if not better.
>>
> with HTML's character entities ); handling POST requests (except with
> the massive overhead of cURL )... It's also an extremely verbose
> language in comparison to the beautiful compactness of Perl...
So you've not tried using the native capability included through sockets?
Pear has a very good PHP class which handles POST requests nicely without
any need to invoke cURL
>
> It's horses for courses, I would try and use PHP for mainly web-based
> applications - but I still find it easier to use Perl in about 10% of
> these cases and in more general data munging.
PHP has a nice set of capabilities, some OO support, and fairly tight
bindings to native C library function cvalls for a lot of functions,
that can make it pretty good. I do think that if you're going to do the
more heavy-duty stuff (indexing a corpus of documents, etc) Perl seems
to have the edge.
Very very quick to build something in PHP, though, especially if you
have a good library of classes - you could probably argue the same thing
for Perl. I might try porting some stuff over, and benchmarking like
against like...
Oh yes, PHP's domxml stuff hogs memory like a dog! I do like Perl, but
a lot of the time PHP can be a quick easy solution. There's also a larger
number of developers available (both good and bad) for future maintenance,
etc
------------------------------
Date: Tue, 19 Aug 2003 23:37:55 +0000 (UTC)
From: "Damian Brown" <damian@phpexpert.org>
Subject: Re: Perl or PHP for web work ?
Message-Id: <bhuccj$5gc$1@hercules.btinternet.com>
simple answer - simple language - use PHP
Regards,
Damian
www.phpexpert.org/chat/
"matty" <matt+nntp@askmenoquestions.co.uk> wrote in message
news:9Gx0b.9315$z7.1117530@wards.force9.net...
> James wrote:
> >>
> >>Use PHP. PHP was designed for the web and Perl, for all its
> >>flexibility and power, was not.
>
> >>
> >>Besides, for your purposes there really isn't anything that Perl
> >>can do that PHP can't do equally as well if not better.
> >>
>
> > with HTML's character entities ); handling POST requests (except with
> > the massive overhead of cURL )... It's also an extremely verbose
> > language in comparison to the beautiful compactness of Perl...
>
> So you've not tried using the native capability included through sockets?
> Pear has a very good PHP class which handles POST requests nicely without
> any need to invoke cURL
>
> >
> > It's horses for courses, I would try and use PHP for mainly web-based
> > applications - but I still find it easier to use Perl in about 10% of
> > these cases and in more general data munging.
>
> PHP has a nice set of capabilities, some OO support, and fairly tight
> bindings to native C library function cvalls for a lot of functions,
> that can make it pretty good. I do think that if you're going to do the
> more heavy-duty stuff (indexing a corpus of documents, etc) Perl seems
> to have the edge.
>
> Very very quick to build something in PHP, though, especially if you
> have a good library of classes - you could probably argue the same thing
> for Perl. I might try porting some stuff over, and benchmarking like
> against like...
>
> Oh yes, PHP's domxml stuff hogs memory like a dog! I do like Perl, but
> a lot of the time PHP can be a quick easy solution. There's also a larger
> number of developers available (both good and bad) for future maintenance,
> etc
>
>
------------------------------
Date: Tue, 19 Aug 2003 23:12:55 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: Problem with FindBin and taint mode under Windows
Message-Id: <bhuatn$t7t$1@holly.rdwarf.com>
Our news server refused to post for a while, and this didn't seem to go
out. I'm still having problems with this, and would very much like any
tips anyone can offer.
Thank you!
Louis Erickson <wwonko@rdwarf.com> wrote:
: I've just run in to a problem on a project I'm working on here, which may
: mean I can't use taint mode on a bunch of CGI scripts. This is not a really
: good solution, and I'd like to figure a way around it.
: When you use FindBin, under ActiveState's Windows perl, it fails right away
: with a taint check.
: As far as I can tell, this is because FindBin calls abs_path to resolve the
: path elements in $Bin and $RealBin. abs_path on Unix is taint-safe.
: On Windows, abs_path is aliased to fast_abs_path, which uses chdir. chdir
: is not taint safe, and therefore FindBin is not taint safe on Windows.
: It looks to me like the only "safe" way to do this would be to write a
: version of abs_path that works on Windows, and then to use that instead
: of fast_abs_path, and to update Cwd to use the new function.
: This is with AS Perl 5.6.1 build 635.
: I'm kind of in a catch-22... I could write my own, but I can't get it in
: to @INC properly without FindBin, and FindBin is the trouble...
: I saw a couple of questions about this in the Usenet archive on Google, and
: a couple of references to it on the Web, but I didn't find a really good
: answer from anyone.
: Is there a way to use FindBin with -T on Windows? Or am I on my own?
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
You may be recognized soon. Hide.
------------------------------
Date: Tue, 19 Aug 2003 21:04:00 -0400
From: Benjamin Goldberg <ben.goldberg@hotpop.com>
Subject: Re: Send Message over UNIX Socket
Message-Id: <3F42C900.48C9D3DE@hotpop.com>
Didatus wrote:
>
> i have a problem to send data over an unix domain socket
> after the socket is created i am reading data from stdin und want to
> send it over socket to a listener but it doesn't work. I don't know
> why. There is no Errormessage. Syswrite only returns false.
What is $! after syswrite returns false?
PS: Your code would be rather clearer (and more correct) if written as:
#!/usr/bin/perl -w
use strict;
use Getop::Long;
use IO qw(Select Socket::UNIX);
my $unix_sock_addr = "";
Getopt::Long::Configure("bundling");
GetOptions ('socket|s=s' => $unix_sock_addr);
my $sockout = IO::Socket::UNIX->new(
PeerAddr => $unix_sock_addr,
Type => SOCK_STREAM,
Timeout => 10,
) or die "Error connecting to unix domain socket: $@";
$sockout->autoflush(1);
my $select = IO::Select->new(\*STDIN);
while( () = $select->can_read(200) ) {
my ($data, $n);
if( $n = sysread( STDIN, $data, 4096 ) )
print $sockout $data or die "Error sending data: $!";
} elsif( defined($n) ) {
print "EOF on stdin\n";
exit;
} else {
die "Error in sysread: $!";
}
}
print "Timeout on stdin\n";
exit;
__END__
[untested]
Yes, IO::Socket::UNIX does set $@ when it fails. (It also sets $!, but
the contents of $@ are often more meaningful.)
Notice that I do NOT call sysread more than once for each time that
can_read returns true. Because of this, I don't need to turn off
blocking on it (which is good, since turning off blocking isn't always
portable).
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
------------------------------
Date: Tue, 19 Aug 2003 20:01:58 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: sub param in CGI.pm
Message-Id: <luo5kv89tsai9k79bdu9c5i2n42l3jr53a@4ax.com>
OK...I dug up the subroutine called param in CGI.pm. Anyone care to give me a little insight into it?
sub param {
my($self,@p) = self_or_default(@_);
return $self->all_parameters unless @p;
my($name,$value,@other);
# For compatibility between old calling style and use_named_parameters() style,
# we have to special case for a single parameter present.
if (@p > 1) {
($name,$value,@other) = rearrange([NAME,[DEFAULT,VALUE,VALUES]],@p);
my(@values);
if (substr($p[0],0,1) eq '-') {
@values = defined($value) ? (ref($value) && ref($value) eq 'ARRAY' ? @{$value} : $value) : ();
} else {
foreach ($value,@other) {
push(@values,$_) if defined($_);
}
}
# If values is provided, then we set it.
if (@values) {
$self->add_parameter($name);
$self->{$name}=[@values];
}
} else {
$name = $p[0];
}
return unless defined($name) && $self->{$name};
return wantarray ? @{$self->{$name}} : $self->{$name}->[0];
}
------------------------------
Date: Tue, 19 Aug 2003 20:22:55 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: sub param in CGI.pm
Message-Id: <5bq5kvkr6us2g5ushpo6hrj354tl6q6ibu@4ax.com>
On Tue, 19 Aug 2003 20:01:58 -0700, hudson
<scripts_you_know_the_drill_@hudsonscripting.com> wrote:
>OK...I dug up the subroutine called param in CGI.pm. Anyone care to give me a little insight into it?
>
>sub param {
> my($self,@p) = self_or_default(@_);
> return $self->all_parameters unless @p;
> my($name,$value,@other);
>
> # For compatibility between old calling style and use_named_parameters() style,
> # we have to special case for a single parameter present.
> if (@p > 1) {
> ($name,$value,@other) = rearrange([NAME,[DEFAULT,VALUE,VALUES]],@p);
> my(@values);
>
> if (substr($p[0],0,1) eq '-') {
> @values = defined($value) ? (ref($value) && ref($value) eq 'ARRAY' ? @{$value} : $value) : ();
> } else {
> foreach ($value,@other) {
> push(@values,$_) if defined($_);
> }
> }
> # If values is provided, then we set it.
> if (@values) {
> $self->add_parameter($name);
> $self->{$name}=[@values];
> }
> } else {
> $name = $p[0];
> }
>
> return unless defined($name) && $self->{$name};
> return wantarray ? @{$self->{$name}} : $self->{$name}->[0];
>}
should I add this?
sub parse_params {
my($self,$tosplit) = @_;
my(@pairs) = split(/[&;]/,$tosplit);
my($param,$value);
foreach (@pairs) {
($param,$value) = split('=',$_,2);
next unless defined $param;
next if $NO_UNDEF_PARAMS and not defined $value;
$value = '' unless defined $value;
$param = unescape($param);
$value = unescape($value);
$self->add_parameter($param);
push (@{$self->{$param}},$value);
}
}
sorry for posting to my own thread...my bad habit ;-)
------------------------------
Date: Tue, 19 Aug 2003 17:36:55 -0700
From: Keith Keller <kkeller-spammmm@wombat.san-francisco.ca.us>
Subject: Re: sub param in CGI.pm
Message-Id: <7rfuhb.mvs.ln@goaway.wombat.san-francisco.ca.us>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
In article <luo5kv89tsai9k79bdu9c5i2n42l3jr53a@4ax.com>, hudson wrote:
> OK...I dug up the subroutine called param in CGI.pm. Anyone care to give me a little insight into it?
What sort of insight are you seeking? Specific questions about lines
of code would be more helpful. (Followup your original post if
you want to do that.)
- --keith
- --
kkeller-mmmspam@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj9CwqYACgkQhVcNCxZ5ID/flQCeP7jQBKbHxlYNxlNeGku7WPgH
qA4Anja5tX5BRpbpkpafNkEX7vjTYsC+
=fUeq
-----END PGP SIGNATURE-----
------------------------------
Date: Tue, 19 Aug 2003 20:50:47 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: sub param in CGI.pm
Message-Id: <1qr5kv0lilndn2bmn92sfkqi70kiivr773@4ax.com>
On Tue, 19 Aug 2003 17:36:55 -0700, Keith Keller
<kkeller-spammmm@wombat.san-francisco.ca.us> wrote:
>What sort of insight are you seeking? Specific questions about lines
>of code would be more helpful. (Followup your original post if
>you want to do that.)
ahh well...maybe you are right and I am asking other people to do work
for me....sorry about that
to explain the post better, though, people here have told me many
times I can't live without CGI.pm ....so I would like to know exactly
what that module does that I can't understand.
anyway, you are right...I really should read the code myself for a
week or a month and come back later with specific questions instead of
asking for a general walkthrough right off the bat
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5392
***************************************
