[23591] in Perl-Users-Digest
Perl-Users Digest, Issue: 5798 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 14 00:06:02 2003
Date: Thu, 13 Nov 2003 21:05:08 -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, 13 Nov 2003 Volume: 10 Number: 5798
Today's topics:
Re: "tree" view of directory (Jay Tilton)
Re: #!perl instead of #!/usr/bin/perl on a Unix/Apache <bobx@linuxmail.org>
Re: #!perl instead of #!/usr/bin/perl on a Unix/Apache (Sam Holden)
Re: #!perl instead of #!/usr/bin/perl on a Unix/Apache <wwonko@rdwarf.com>
Re: (exit $?0) - challenge <usenet@morrow.me.uk>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <emschwar@pobox.com>
Re: arrange form data in same order as on form <bxtrap01@comcast.net>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <usenet@morrow.me.uk>
Re: arrange form data in same order as on form <asu1@c-o-r-n-e-l-l.edu>
Re: arrange form data in same order as on form <kkeller-usenet@wombat.san-francisco.ca.us>
Re: bit sequence match (Jay Tilton)
Re: Evaluating nester variables <noreply@gunnar.cc>
Re: Evaluating nester variables <jurgenex@hotmail.com>
Re: Evaluating nester variables <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 14 Nov 2003 02:49:45 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: "tree" view of directory
Message-Id: <3fb438a6.102337074@news.erols.com>
Mike Flannigan <mikeflan@earthlink.net> wrote:
: Interestingly, now the program only prints:
: "<ul><li> Io.sys </li><li> Msdos.sys </li></ul>"
:
: Never mind - apparently that is exactly what it's supposed to
: do on an empty directory.
Is the directory really empty?
Those two files are typically found in the root directory of the boot
partition on a Windows box. It would be unusual for that partition to
have nothing else.
One thing that can send the program off its rails is if you start it in
a volume's root directory, e.g.
perl file.pl c:/
Then, because it uses "$dir/$file" to concatenate the directory with the
filename, it will try to stat filenames like "c://foo" . You might look
at the catfile() method in the File::Spec module to do this part of the
task handily and portably.
: It works now - sort of. It just
: doesn't list the paths very good.
It doesn't list directory names at at all, only the files within
directories. It can easily be modified to print the directory names
before listing the files within the directory.
foreach my $directory (@directories) {
print "<li><b>$directory</b></li>";
readADir($directory);
}
: Call me stupid, but I don't know why the original programer
: did the <ul> <li> stuff. Must be some kind of html or something.
Yup. Looking at the output in a web browser shows spiffily indented
tree-like lists of filenames.
------------------------------
Date: Fri, 14 Nov 2003 02:39:54 GMT
From: "Bob X" <bobx@linuxmail.org>
Subject: Re: #!perl instead of #!/usr/bin/perl on a Unix/Apache webserver
Message-Id: <_fXsb.660$_i1.468412@news2.news.adelphia.net>
"Josef Möllers" <josef.moellers@fujitsu-siemens.com> wrote in message
news:3FB37774.8EA139B9@fujitsu-siemens.com...
joe wrote:
>
> Hi there!
>
> Can anyone help me out here. I run my CGI-scripts locally on a Windows
> machine. In the shebang line I put #!c:\www\Perl.exe, but it's also
possible
> to use only #!perl. On my virtual webserver at my ISP's Unix machine I
have
> to use #!/usr/bin/perl.
>AFAIK it is irrelevant _what_ command you put into the shebang line on a
>windows system. Windows doesn't know shebang lines (it maybe knows a .pl
>extension, though), but the perl interpreter knows how to extract
>options (e.g. -w) from the shebang line.
Actually if you are going to doing web work on Windows then the #!perl is
necessary.
------------------------------
Date: 14 Nov 2003 02:55:46 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: #!perl instead of #!/usr/bin/perl on a Unix/Apache webserver
Message-Id: <slrnbr8h1i.tsu.sholden@flexal.cs.usyd.edu.au>
On Fri, 14 Nov 2003 02:39:54 GMT, Bob X <bobx@linuxmail.org> wrote:
>
> "Josef Möllers" <josef.moellers@fujitsu-siemens.com> wrote in message
> news:3FB37774.8EA139B9@fujitsu-siemens.com...
> joe wrote:
>>
>> Hi there!
>>
>> Can anyone help me out here. I run my CGI-scripts locally on a Windows
>> machine. In the shebang line I put #!c:\www\Perl.exe, but it's also
> possible
>> to use only #!perl. On my virtual webserver at my ISP's Unix machine I
> have
>> to use #!/usr/bin/perl.
>
>>AFAIK it is irrelevant _what_ command you put into the shebang line on a
>>windows system. Windows doesn't know shebang lines (it maybe knows a .pl
>>extension, though), but the perl interpreter knows how to extract
>>options (e.g. -w) from the shebang line.
>
> Actually if you are going to doing web work on Windows then the #!perl is
> necessary.
No it isn't. Some web servers may require that, but that's the web server
not windows.
--
Sam Holden
------------------------------
Date: Fri, 14 Nov 2003 04:07:52 +0000 (UTC)
From: Louis Erickson <wwonko@rdwarf.com>
Subject: Re: #!perl instead of #!/usr/bin/perl on a Unix/Apache webserver
Message-Id: <bp1keo$kbb$1@holly.rdwarf.com>
Sam Holden <sholden@flexal.cs.usyd.edu.au> wrote:
: On Fri, 14 Nov 2003 02:39:54 GMT, Bob X <bobx@linuxmail.org> wrote:
:> "Josef Mollers" <josef.moellers@fujitsu-siemens.com> wrote in message
:> news:3FB37774.8EA139B9@fujitsu-siemens.com...
:> joe wrote:
:>>
:>> Can anyone help me out here. I run my CGI-scripts locally on a Windows
:>> machine. In the shebang line I put #!c:\www\Perl.exe, but it's also
:> possible
:>> to use only #!perl. On my virtual webserver at my ISP's Unix machine I
:> have
:>> to use #!/usr/bin/perl.
:>
:>>AFAIK it is irrelevant _what_ command you put into the shebang line on a
:>>windows system. Windows doesn't know shebang lines (it maybe knows a .pl
:>>extension, though), but the perl interpreter knows how to extract
:>>options (e.g. -w) from the shebang line.
:>
:> Actually if you are going to doing web work on Windows then the #!perl is
:> necessary.
: No it isn't. Some web servers may require that, but that's the web server
: not windows.
And, sometimes it varies even within the same web server.
Apache for Windows, for instance, has a way to associate Perl with AS Perl
that doesn't depend on #! pointing anywhere in particular. But, if you
use FastCGI, the #! must be correct.
IIS uses a static mapping of program or ISAPI DLL to extension, so .pl
and .plx are always handled by ActiveState Perl.
Note that Apache's mapping of .pl files and IIS's mapping of .pl files
are entirely different. IIS uses it's own configuration via the IIS MMC,
and Apache uses a registry entry. Or maybe a different registry entry,
depending on your configuration.
Isn't CGI fun?
--
Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/
If you're not part of the solution, you're part of the precipitate.
------------------------------
Date: Fri, 14 Nov 2003 03:01:44 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: (exit $?0) - challenge
Message-Id: <bp1gio$m99$2@wisteria.csv.warwick.ac.uk>
Ara.T.Howard@noaa.gov wrote:
> --
>
> ATTN: please update your address books with address below!
>
> =============================================================================
> | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> | PHONE :: 303.497.6469
> | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
> | STP :: http://www.ngdc.noaa.gov/stp/
> | NGDC :: http://www.ngdc.noaa.gov/
> | NESDIS :: http://www.nesdis.noaa.gov/
> | NOAA :: http://www.noaa.gov/
> | US DOC :: http://www.commerce.gov/
> |
> | The difference between art and science is that science is what we
> | understand well enough to explain to a computer.
> | Art is everything else.
> | -- Donald Knuth, "Discover"
> |
> | /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done'
> =============================================================================
I should trim that down a bit... I believe four lines is normally
considered sufficient.
Ben
--
perl -e'print map {/.(.)/s} sort unpack "a2"x26, pack "N"x13,
qw/1632265075 1651865445 1685354798 1696626283 1752131169 1769237618
1801808488 1830841936 1886550130 1914728293 1936225377 1969451372
2047502190/' # ben@morrow.me.uk
------------------------------
Date: 14 Nov 2003 02:05:52 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns9432D69FBF259asu1cornelledu@132.236.56.8>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp1c15$1in3ke$1@ID-
184292.news.uni-berlin.de:
> Eric Schwartz wrote:
>> Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>>>>>> bbxrider wrote:
>>>>>>
>>>>>>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>>>
>>> Still don't understand what it is that makes the above code
>>> "buggy".
>>
>> The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer,
>> and there's no attempt made to detect or handle this event.
>
> Some kind of exception handling is most often useful, but the lack of
> it isn't exactly a _bug_, is it?
OK, you can call it something else then. Let's assume you don't care about
that. There is still the fact that
>>>>>>> @pairs = split(/&/, $buffer);
will miss pairs separated by a semicolon. In addition, parameter names are
not unescaped. What happens when the query string given is
?param=;
> I very much dislike the aggressive way in which some people here
> advocate the use of CGI, and the lack of faith that is shown in
> people's own judge.
As Eric Roode pointed out, the same exact code has been posted here
numerous times (e.g. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8
&oe=UTF-8&safe=off&selm=4096148f.0310161157.9400327%40posting.google.com)
so I assumed the OP was not relying on his own judgement, but using someone
else's code. In that case, he is better off using CGI.pm.
Sinan.
--
A. Sinan Unur
asu1@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:uce@ftc.gov
------------------------------
Date: 14 Nov 2003 02:07:39 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns9432D6ECAE928asu1cornelledu@132.236.56.8>
"Eric J. Roode" <REMOVEsdnCAPS@comcast.net> wrote in
news:Xns9432C1A592BAFsdn.comcast@216.196.97.136:
> "bbxrider" <bxtrap01@comcast.net> wrote in
> news:7cUsb.139690$mZ5.963708@attbi_s54:
...
>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>> @pairs = split(/&/, $buffer);
>> foreach $pair (@pairs) {
>> ($name, $value) = split(/=/, $pair);
>> $value =~ tr/+/ /;
>> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
>> $FORM{$name} = $value;
...
> We keep seeing this exact same bad code posted to this newsgroup. Out
> of curiosity, where did you copy it from?
It seems to date back to 1996 or even earlier:
http://tinyurl.com/uxq2
--
A. Sinan Unur
asu1@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:uce@ftc.gov
------------------------------
Date: Thu, 13 Nov 2003 19:03:31 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: arrange form data in same order as on form
Message-Id: <etobrrf4sgc.fsf@fc.hp.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Some kind of exception handling is most often useful, but the lack of
> it isn't exactly a _bug_, is it?
Is this buggy?
open(FH, '>', "/root/file");
print FH @data;
I'd say heck yeah, because there's no checking that FH was properly
opened, and that's the exact same class of bug we're talking about in
the OP.
>> Without going to the effort of reading the original post I don't
>> know for sure, but I'd bet there's at least three or four other
>> instances where CGI.pm handles things correctly that the OP's code
>> does not.
>
> None of us knows which of those "things" that are _applicable_ in OP's
> program.
Does it matter? As long as there are any, it means that using CGI.pm
(or some equivalent, such as CGI::Lite, or what-have-you) is a better
solution than rolling it on your own. Again, I make exceptions for
doing it for personal learning purposes, because it's good to learn
how to do things, but it's just nuts to not use a module in a
production environment.
>> Given the option of using known-good code and
>> hacking something up yourself, why (other than learning
>> excercises, which are surely valuable) would you not use the tested
>> and verified code?
>
> I very much dislike the aggressive way in which some people here
> advocate the use of CGI, and the lack of faith that is shown in
> people's own judge. The described attitude makes me suspicious and
> less inclined to listen. How about that for a reason? :)
I know you're being snarky, but I'll answer it honestly: it sucks as a
reason. It's juvenile and immature, and overlooks the real benefits
in favour of rebellion for its own sake. It's not that I have a lack
of faith in people's judgement, it's that I have never-- not *once*--
seen hand-rolled CGI parsing code on this newsgroup that wasn't buggy.
Most of the arguments against using CGI.pm, including "it's too slow",
aren't based on facts, they're based on suppositions, and "well, it
stands to reason". Sometimes they're based on facts, and then people
usually agree that that's a bad case to use it in, but I'd
conservatively estimate that 98% of the time it's the way to go.
I'll grant you, there are times when it's a good idea to roll your own
CGI parsing routines. Personal study is one. I can't think of any
situation for which I'd want to CGI.pm that it doesn't already work
for, but if there is one, that's a good reason-- though a better idea,
IMO, is to fix CGI.pm and thus make everyone's life that much better.
Sometimes you don't need the HTML generation routines, and in that
case there are modules like CGI::Lite and others that do the parsing
job for you.
In the end, there are a gazillion ways to get it wrong, and only a
very few ways to do it right. And people being people, the sort of
person who thinks they're saving time and effort by not using CGI.pm
(or equivalent) is not as a rule the sort of person that's going to
take the very painstaking approach of reading the RFCs and following
them correctly, leading to the
10 Hey, it works for me.
20 <tweak>
30 Oh, crap, now it's broke. <code>
40 GOTO 10
loop we're all so painfully familiar with.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: Fri, 14 Nov 2003 02:24:04 GMT
From: "bbxrider" <bxtrap01@comcast.net>
Subject: Re: arrange form data in same order as on form
Message-Id: <81Xsb.144719$ao4.463347@attbi_s51>
thanks for all the help and opinions
i'm just self learning perl and found some code at
http://www.cgi101.com/class/
and some other searching google groups
actually i dont even know what cgi.pm and cgi lite are but will surely find
out
i dont' mean to try and just steal code, but have found that seeing, using
and understanding examples
really accelerates my learing curve
what i've since found is that the variable containing the form input is in
fact in the same order as the form
this code keeps the original order
foreach (split(/[&;]/, $buffer)) {
s/\+/ /g ;
($name, $value)= split('=', $_, 2) ;
$name=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
$value=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
print "$name = $value";
$buffer{$name}.= "\0" if defined($in{$name}) ; # concatenate
multiple vars
$buffer{$name}.= $value ;
}
i have already set up sql query based inserts that expect the data fields in
order and since there are 67
on the form i want to be able to reuse that code
again thanks for the help, this is a great forum and would hope to return
the help someday
"Eric J. Roode" <REMOVEsdnCAPS@comcast.net> wrote in message
news:Xns9432C1A592BAFsdn.comcast@216.196.97.136...
> -----BEGIN xxx SIGNED MESSAGE-----
> Hash: SHA1
>
> "bbxrider" <bxtrap01@comcast.net> wrote in
> news:7cUsb.139690$mZ5.963708@attbi_s54:
>
> > is there a way to sort (or other method) the 'method=post' data
> > fields from a form into
> > the same order they appear in the form
> > when i use the following code there doesn't appear to be any
> > particular order to how they are arranged
>
> The CGI spec does not guarantee that the form variables will be submitted
> in any particular order, so you're out of luck.
>
> > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> > @pairs = split(/&/, $buffer);
> > foreach $pair (@pairs) {
> > ($name, $value) = split(/=/, $pair);
> > $value =~ tr/+/ /;
> > $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> > $FORM{$name} = $value;
>
> This is exceedingly bad code. Unless you really know what you're doing,
> and have strong reasons not to, you should use the CGI module.
>
> We keep seeing this exact same bad code posted to this newsgroup. Out of
> curiosity, where did you copy it from?
>
> - --
> Eric
> $_ = reverse sort $ /. r , qw p ekca lre uJ reh
> ts p , map $ _. $ " , qw e p h tona e and print
>
> -----BEGIN xxx SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBP7Qbf2PeouIeTNHoEQKb6gCfbgrhGAcLpyRLTC5cUW4U1AsVIsQAn3Ev
> bAiVGyJb/3J4v/fhU4Yi9w1q
> =vDoO
> -----END PGP SIGNATURE-----
------------------------------
Date: Fri, 14 Nov 2003 04:15:35 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp1hn3$1is5k8$1@ID-184292.news.uni-berlin.de>
A. Sinan Unur wrote:
> There is still the fact that
>
>>>>>>>>@pairs = split(/&/, $buffer);
>
> will miss pairs separated by a semicolon.
Not applicable. Look at OP's original post again. Parameters submitted
via forms using the POST method are not separated by semicolons.
> In addition, parameter names are
> not unescaped. What happens when the query string given is
>
> ?param=;
Nothing, since the code does not parse query strings.
I know that you know better than that, Sinan. But now we are talking
about the 'sacred cow' CGI.pm, so the usually educated, logical posts
from you are suddenly replaced with incorrect or questionable
statements. It's anything but convincing.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 14 Nov 2003 04:15:44 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp1hn6$1is5k8$2@ID-184292.news.uni-berlin.de>
Eric Schwartz wrote:
> Gunnar Hjalmarsson writes:
>> I very much dislike the aggressive way in which some people here
>> advocate the use of CGI, and the lack of faith that is shown in
>> people's own judge. The described attitude makes me suspicious
>> and less inclined to listen. How about that for a reason? :)
>
> I know you're being snarky, but I'll answer it honestly: it sucks
> as a reason. It's juvenile and immature, and overlooks the real
> benefits in favour of rebellion for its own sake.
Maybe true, when you look at it from a rational angle. But it's human.
See my latest reply to Sinan. (This is my last post in this thread, I
promise. :) )
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 14 Nov 2003 03:25:02 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp1hue$mj7$2@wisteria.csv.warwick.ac.uk>
[please don't top-post]
"bbxrider" <bxtrap01@comcast.net> wrote:
> thanks for all the help and opinions i'm just self learning perl and
> found some code at http://www.cgi101.com/class/ and some other
> searching google groups actually i dont even know what cgi.pm and
> cgi lite are but will surely find out
For CGI, type 'perldoc CGI' at a command prompt. CGI::Lite you would
need to install. Note that the names of Perl modules are case-sensitive.
> i dont' mean to try and just steal code, but have found that seeing,
> using and understanding examples really accelerates my learing curve
Absolutely. Reading decent code is one of the best ways to learn. You
do have to be sure your source is reliable, though: there is one hell
of a lot of very bad Perl floating around the web.
> what i've since found is that the variable containing the form input
> is in fact in the same order as the form this code keeps the
> original order
I don't think this is guaranteed, by which I mean that it may happen
to work for you with your browser during this phase of the moon, but
under other circumstances it may well not. If you need to keep
separate track of the different paramaters, give them different
names. Change whatever generates them to put a number on the end, or
something.
Ben
--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * ben@morrow.me.uk
------------------------------
Date: 14 Nov 2003 03:29:49 GMT
From: "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns9432E4DB0F410asu1cornelledu@132.236.56.8>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp1hn3$1is5k8$1@ID-
184292.news.uni-berlin.de:
> A. Sinan Unur wrote:
>
>> In addition, parameter names are not unescaped.
>> What happens when the query string given is
>>
>> ?param=;
>
> Nothing, since the code does not parse query strings.
Hmmmm ... Let's say I have been doing too much 'task-switching' today,
leading to muddled thinking.
> But now we are talking about the 'sacred cow' CGI.pm, so the
> usually educated, logical posts from you are suddenly replaced with
> incorrect or questionable statements.
It is not that ... Simply jumbled neural paths or something. I do
apologize.
Sinan.
--
A. Sinan Unur
asu1@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:uce@ftc.gov
------------------------------
Date: Thu, 13 Nov 2003 19:49:55 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: arrange form data in same order as on form
Message-Id: <3dj1pb.ic3.ln@goaway.wombat.san-francisco.ca.us>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
On 2003-11-14, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>
> Not applicable. Look at OP's original post again. Parameters submitted
> via forms using the POST method are not separated by semicolons.
What if he wants to support GET in the future?
> Nothing, since the code does not parse query strings.
What if he wants to parse query strings in the future?
- --keith
- --
kkeller-usenet@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.2.3 (GNU/Linux)
iD8DBQE/tFDihVcNCxZ5ID8RApBfAJ90LhcK0PGkyyZv/7q5Mhfag4/rogCeLNcn
MIWcADFGVC1a1mzcW+V1Nvc=
=GtN2
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 14 Nov 2003 02:52:03 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: bit sequence match
Message-Id: <3fb442e3.104958514@news.erols.com>
Edo <edady2002@yahoo.com> wrote:
: this is working but I need to understand how it worked. as still
: learning perl. and after reading all what I can find in the programming
: perl book about pack.
In the third edition of Programming Perl, the core functions are
explained in chapter 29.
An explanation of pack() is also available on your own machine by typing
"perldoc -f pack" at a shell prompt.
: could you explain in details what this line do
:
: my $look_for = pack('(B6)*' => @h1{ @k1 });
Let's break it down into pieces.
"@k1" is an array containing the keys to %h1, in the desired sorted
order.
"@h1{ @k1 }" is a hash slice (see "Slices" in perldata). It returns a
list of the values in %h1 for the keys listed in @k1. A hash slice is a
convenient way to access several hash values at once. In this case, it
does the same thing as saying
( $h1{$k1[0]}, $h1{$k1[1]}, $h1{$k1[2]}, ... )
Significantly, the hash slice returns values in a desired order. If we
had said "values %h1" we would have no control over the order.
Becoming familiar with hash, array, and list slices is one of the best
things you can do while learning Perl. Only a small effort is needed to
do powerful things.
The "=>" is a "fat comma." There's no reason why an ordinary comma
couldn't be used there instead. It's strictly a style preference in
this case.
The "B6" in the pack template creates one character from a 6-bit string
of 0's and 1's, in descending bit order. Since we're only going to use
the string created by pack() in an equivalence comparison with another
pack()ed string, the bit order itself is less important than staying
consistent.
The "(...)*" in the pack template uses a feature introduced with Perl
5.8.0. The "*" repeater tells pack() to apply the parenthesized
sub-template to the entire list of values. Put together,
pack('(B6)*', ... );
ends up doing the same thing as saying,
pack('B6 B6 B6', ... );
except that you don't need to know there are three values to be packed.
The "my $look_for = ..." assignment should be familiar syntax.
I think that explains what's going on. Ask for clarification of
anything I glossed over. Anybody else with something to add or correct
will speak up.
------------------------------
Date: Fri, 14 Nov 2003 03:16:37 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Evaluating nester variables
Message-Id: <bp1e8c$1ho45p$1@ID-184292.news.uni-berlin.de>
Have you read the posting guidelines yet? Not complying with them will
make people here ignore you.
Geoff wrote:
> You are correct, I am not dealing with references. The code should
> generate this:
> @values=($name0, $phone0, $name1, $phone1,... $namen, $phonen)
>
> $name0 get's set by the below function that reads all incoming CGI
> variables and turns them into perl variables:
> sub getCGIVariables {
> my $qname = '';
> my $qvalue = '';
> while(($qname, $qvalue) = each %in) {
> $$qname = $qvalue;
> }
> } # end
>
> I've tried using "print eval $values[0];", but that returns "$name0".
Then it seems as if you need to do some debugging.
I must say that creating all those scalar variables makes little sense
to me. You really should take a step back, read some _good_ book about
basic Perl programming, and reconsider the approach in your program.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 14 Nov 2003 02:52:13 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Evaluating nester variables
Message-Id: <xrXsb.38362$E9.31179@nwrddc01.gnilink.net>
[Please do not top post]
[Please do not blindly fullquote]
"Geoff" wrote :
> You are correct, I am not dealing with references.
Unfortunately you are, with symbolic references :-((
> The code should generate this:
[...]
> $$qname = $qvalue;
[...]
Are you sure you know what you are doing and why you are using them?
And what limitations and problems they have?
I _strongly_ recommend you read the FAQ 'perldoc -q "variable name"'
jue
------------------------------
Date: Fri, 14 Nov 2003 02:57:14 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Evaluating nester variables
Message-Id: <x74qx7slmd.fsf@mail.sysarch.com>
>>>>> "G" == Geoff <gtb104gtb@netscape.net> writes:
don't top post. see the posting guidelines (posted regularly here)
G> OK. Well, the string that comes from the HTML looks like so:
G> action=add&name1=tom&phone1=123&name2=bob&phone2=456.... and so on.
G> Why you ask? Because I have a block of input fields like:
G> Name: |________________|
G> Phone: |________________|
G> If you enter data into the form, then click the add button, the
G> Javascript needs to save the existing data into an array, so that when
G> the form is redrawn, it populates the fileds you've already entered
G> data into.
blech. that can be done server side with little effort. it is built in
to cgi.pm (sticky values i think it is called).
G> The way I figured out to do this was to increment the variable names
G> by 1 so that the right data goes into the right fields.
those aren't variable but form fields. and my comment was on the sql
part more than the html stuff. if you have multiple common fields, then
using incremental names in sql makes little sense as you can't
(easily) add columns as needed. your whole design needs a big rethink
before you get into deeper spaghetti trouble.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
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 5798
***************************************
