[26129] in Perl-Users-Digest
Perl-Users Digest, Issue: 8322 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 14 18:05:38 2005
Date: Sun, 14 Aug 2005 15:05:05 -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 Sun, 14 Aug 2005 Volume: 10 Number: 8322
Today's topics:
Re: basic cgi button question <flavell@ph.gla.ac.uk>
Re: basic cgi button question <k.p.boomsma@xs4all.nl>
Re: basic cgi button question <flavell@ph.gla.ac.uk>
Re: How do I use global variables safely? <graham@letsgouk.com>
Re: How do I use global variables safely? <djames@thehub.com.au>
Re: Manually parsing quoted characters <krevlar.newsgroups@tragetaschen.dyndns.org>
Re: mod_gzip and perl <spam-block-@-SEE-MY-SIG.com>
Re: mod_gzip and perl <flavell@ph.gla.ac.uk>
Re: OT basic cgi button question <k.p.boomsma@xs4all.nl>
Re: OT basic cgi button question <noreply@gunnar.cc>
Re: Probs with regex and nesting <nobull@mail.com>
test if entry in hash ref is an array or a string? <sengc#rm_me#@web.de>
Re: test if entry in hash ref is an array or a string? <matthew.garrish@sympatico.ca>
Re: test if entry in hash ref is an array or a string? <sengc#rm_me#@web.de>
Re: test if entry in hash ref is an array or a string? <noreply@gunnar.cc>
Re: test if entry in hash ref is an array or a string? <sengc#rm_me#@web.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 14 Aug 2005 14:49:14 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: basic cgi button question
Message-Id: <Pine.LNX.4.62.0508141425310.506@ppepc56.ph.gla.ac.uk>
On Sun, 14 Aug 2005, Kornelis wrote:
> I settled on posting here, because more cgi related groups that I
> could find on my newsserver all had a very low output.
Well, I think you've had answers to your substantive question now,
from at least two of us here (Gunnar and myself), but I'm afraid you
lose some usenet brownie points for that reply...
You remind me of the fellow who lost a dollar in a dark corner, but
looks for it under the street lamp where it's easier to search.
If you're talking about comp.infosystems.www.authoring.cgi (beware its
automoderation bot) then be assured that there are people reading it,
even if the traffic is quite low, and a reasonable question is likely
to elicit one or more reasonable responses.
Whereas folks who continue to post here with questions that are
evidently about CGI - and have very little Perl content - are doomed
to very quickly exhaust their supply of usenet brownie points, as a
review of previous postings here would reveal. I'm just telling you
this in your own interest (and for the benefit of anyone else who
happens to be reading) - it's the way things are around here.
As we often say, the key to solving a complex problem is understanding
how to partition it into smaller problem domains. Everyone who is in
that kind of situation needs to develop expertise in doing that, and
in that sense, partitioning your kind of problem into the HTML markup,
the client agent (browser) submission action, the server-side CGI
(software interface), and the coding of a CGI process in one or other
appropriate language, are all a part of that problem-solving activity,
and the partitioning should help to focus on an appropriate
usenet group for their problem. The Perlfaq9 also points out that
problems that appear to be about the CGI have their own usenet group,
and that this (c.l.p.misc) isn't it.
Anyone who's genuinely still having difficulty with the partitioning
aspect of problem solving would, I think, get an initially sympathetic
reception here, but only in the sense of being urged to concentrate on
their problem-solving practice, to improve their problem domain
partitioning. Usenet likes to help those who say enough to reveal
that they are trying to help themselves - and searching under the
streetlamp where the light is better does not really give the readers
the right impression, I think it's fair to say.
Anyway, I've had my rant. I won't press the point any further.
Good luck.
------------------------------
Date: Sun, 14 Aug 2005 17:36:22 +0200
From: Kornelis <k.p.boomsma@xs4all.nl>
Subject: Re: basic cgi button question
Message-Id: <42ff623c$0$11077$e4fe514c@news.xs4all.nl>
Alan J. Flavell wrote:
> On Sun, 14 Aug 2005, Kornelis wrote:
>
>
>>I settled on posting here, because more cgi related groups that I
>>could find on my newsserver all had a very low output.
>
>
> Well, I think you've had answers to your substantive question now,
> from at least two of us here (Gunnar and myself), but I'm afraid you
> lose some usenet brownie points for that reply...
>
> You remind me of the fellow who lost a dollar in a dark corner, but
> looks for it under the street lamp where it's easier to search.
>
> If you're talking about comp.infosystems.www.authoring.cgi (beware its
> automoderation bot) then be assured that there are people reading it,
> even if the traffic is quite low, and a reasonable question is likely
> to elicit one or more reasonable responses.
>
> Whereas folks who continue to post here with questions that are
> evidently about CGI - and have very little Perl content - are doomed
> to very quickly exhaust their supply of usenet brownie points, as a
> review of previous postings here would reveal. I'm just telling you
> this in your own interest (and for the benefit of anyone else who
> happens to be reading) - it's the way things are around here.
>
> As we often say, the key to solving a complex problem is understanding
> how to partition it into smaller problem domains. Everyone who is in
> that kind of situation needs to develop expertise in doing that, and
> in that sense, partitioning your kind of problem into the HTML markup,
> the client agent (browser) submission action, the server-side CGI
> (software interface), and the coding of a CGI process in one or other
> appropriate language, are all a part of that problem-solving activity,
> and the partitioning should help to focus on an appropriate
> usenet group for their problem. The Perlfaq9 also points out that
> problems that appear to be about the CGI have their own usenet group,
> and that this (c.l.p.misc) isn't it.
>
> Anyone who's genuinely still having difficulty with the partitioning
> aspect of problem solving would, I think, get an initially sympathetic
> reception here, but only in the sense of being urged to concentrate on
> their problem-solving practice, to improve their problem domain
> partitioning. Usenet likes to help those who say enough to reveal
> that they are trying to help themselves - and searching under the
> streetlamp where the light is better does not really give the readers
> the right impression, I think it's fair to say.
>
> Anyway, I've had my rant. I won't press the point any further.
>
> Good luck.
I alreadly tried to apologize, even though in retrospect the words I used
seem to fall short of "het spijt mij", and my confession that I could not
find other groups that posted as much on this topic, naive. As for the rant,
it only hurts me, and tells me to go away, which I will.
------------------------------
Date: Sun, 14 Aug 2005 17:38:26 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: basic cgi button question
Message-Id: <Pine.LNX.4.62.0508141731040.506@ppepc56.ph.gla.ac.uk>
On Sun, 14 Aug 2005, Kornelis wrote:
> Alan J. Flavell wrote:
[snipped comprehensive quote]
> As for the rant, it only hurts me, and tells me to go away, which I
> will.
Then it's a pity that I spent time and effort trying to write
something helpful for you (and anyone else who might benefit from it).
If I'd wanted to tell you to get lost, I could have done it with so
much less effort. Ho hum. Anyway, this isn't my personal usenet
group, not by a long way: I was only trying to summarise for you (with
what were supposed to be helpful suggestions) the general attitude of
this group to questions that don't have much Perl content to them, as
learned from a longer period of participating here myself.
If and when you have a question about using the Perl language, which
also just happens to concern the CGI, then I'm sure the group will be
only too happy to deal with your question in detail.
I'm done with this thread now.
good luck
------------------------------
Date: Sun, 14 Aug 2005 14:12:19 +0100
From: "Graham" <graham@letsgouk.com>
Subject: Re: How do I use global variables safely?
Message-Id: <42ff445b.0@entanet>
> You can just declare the variable in a scope that both subs can see:
> --Damian
Silly me!. Yes, as Damian says, if I declare those variables which will be
used in more than one subroutine at the top of the file, before any
subroutines are invoked, everything is honky dory. Also, I don't think
PerlApp was forcing me to 'use strict' after all - that was another problem
which I've now overcome.
--Graham
------------------------------
Date: Sun, 14 Aug 2005 21:00:03 GMT
From: Damian James <djames@thehub.com.au>
Subject: Re: How do I use global variables safely?
Message-Id: <slrndfva8u.344.djames@puli.home>
On Sun, 14 Aug 2005 14:12:19 +0100, Graham said:
> PerlApp was forcing me to 'use strict' after all - that was another problem
> which I've now overcome.
All the same, I'd strongly suggest using strict anyway, and warnings.
It will save you time and effort in the long run.
--Damian
------------------------------
Date: Sun, 14 Aug 2005 23:38:31 +0200
From: Arne Ruhnau <krevlar.newsgroups@tragetaschen.dyndns.org>
Subject: Re: Manually parsing quoted characters
Message-Id: <ddodkp$blc$03$1@news.t-online.com>
Gary E. Ansok wrote:
> In article <42fb3422$0$18200$db0fefd9@news.zen.co.uk>,
> Dave Weaver <zen13097@zen.co.uk> wrote:
>
>>Arne Ruhnau <krevlar.newsgroups@tragetaschen.dyndns.org> wrote:
>>
>>> is there some simpler/more elegant solution to the following problem:
>>> given a string 'a\|b|c', transform it into the list ('a|b', 'c')
>>
>>Here's my attempt, splitting using a negative lookbehind assertion,
>>i.e. only splitting on a | if it's not preceded by a \
>>
>>#!/usr/bin/perl
>>use strict;
>>use warnings;
>>use Data::Dumper;
>>
>>my @list = map { s/\\\|/|/g; $_ } split /(?<!\\)\|/, 'a\|b|c';
>>print Dumper \@list;
>>
>>__END__
<snip output>
>
> That runs into the question of how the string 'a\\|b|c' should be
> treated -- should it result in [ 'a\', 'b', 'c' ] ? If so, then
> a little more work needs to be put into the code.
It should be read from left to right, thus resulting in ['a\', 'b', 'c'].
After thinking all this over, I came to realize that there is nothing as
elegant as lexing my (a|b|c)-lists into something like
[OPENLIST],
[ELEMENT, a],[DELIMITER],[ELEMENT, b],[DELIMITER],[ELEMENT, c],
[CLOSELIST]
and then to parse it into ['a', 'b', 'c'] - which is what i need for the
rest of the language.
'a\\|b|c' would be lexed as
[ELEMENT, 'a\'], [DELIMITER], ...
I just had to define a lexer which takes care of backslash-quoted
characters, the rest would be simple enough.
The rest of my code to parse my simple language works this way, but naively
I thought it would be possible to simply hack (..|..)-constructs into it.
Too lazy, too much hybris and way to impatient...
I'll post my solution when it is done the way i think it should be done.
Thanks for your thoughts,
Arne Ruhnau
------------------------------
Date: Sun, 14 Aug 2005 18:52:50 +0100
From: James Taylor <spam-block-@-SEE-MY-SIG.com>
Subject: Re: mod_gzip and perl
Message-Id: <ant141750063fNdQ@riscpc.jtnet>
In article <Pine.LNX.4.62.0508141010010.506@ppepc56.ph.gla.ac.uk>,
Alan J. Flavell <flavell@ph.gla.ac.uk> wrote:
>
> Internet Explorer deliberately rules itself out as a web-compatible
> browser, by several violations of mandatory requirements of the
> applicable interworking specifications.
Can you point me to something describing the precise details of
the alleged violations? (No, I'm not surprised either.)
--
James Taylor, London, UK PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.
------------------------------
Date: Sun, 14 Aug 2005 21:24:51 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: mod_gzip and perl
Message-Id: <Pine.LNX.4.62.0508142046410.5058@ppepc56.ph.gla.ac.uk>
On Sun, 14 Aug 2005, James Taylor wrote:
> Can you point me to something describing the precise details of
> the alleged violations?
Well, this is rather off-topic for the present group, but you've asked
a straight question, so I'll try to offer a straight answer.
However, let's move this to a more-appropriate group if any discussion
develops, please!
I'll give you a couple, at least.
RFC2616 section 7.2.1 says:
___
/
When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding. These define a two-layer, ordered encoding model:
entity-body := Content-Encoding( Content-Type( data ) )
Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource.
\___
Note carefully the "if and only if". In practice, HTTP servers always
*do* send a Content-type header along with the response to any
HTTP/1.0 or /1.1 transaction - *but* MSIE consistently disregards the
content-type returned by the server (they even document this
violation, although without admitting it for what it is), and attempts
to make its own evaluation of the content type instead, in violation
of this mandatory requirement of the IETF protocol specification.
This means that IE rules itself out of the HTTP protocol.
Now take a look at the CSS specification. CSS/2.1 will suffice: start
with the bit near the end of the section on conformance,
http://www.w3.org/TR/CSS21/conform.html
and in particular, follow the link "user agents must observe the rules
for handling parsing errors", keeping in mind the meaning of "must" in
such a specification.
The link takes us to section 4.2:
http://www.w3.org/TR/CSS21/syndata.html#parsing-errors
However, where the specification mandates here that user agents *must*
disregard various kinds of illegal values - MSIE guesses at what the
illegal values might have been intended to be, and actions those
guesses. (You'd have thought they might have learned someething from
the mess that they created with draft CSS in MSIE3.*, but it seems
not). You'll find essentially the same mandates in CSS1 and CSS2,
this isn't by any means exclusive to CSS2.1. So IE rules itself out as
a conforming CSS user agent as defined by the W3C.
The fact that IE also fails to implement parts of HTML4, and
implements some other parts wrongly , could be rated less severe from
a barrack-room-lawyer's point of view, in as much as there's no actual
mandate to implement HTML4 - nor even to implement it correctly. In
fact, MSIE does not include "text/html" in its HTTP "Accept:" header,
so our barrack-room-lawyer would be fully entitled to send IE
something else (plain text, Microsoft Word format, you name it) and
never send it HTML - though that might not be well received by some
web readers who still think that MSIE is a web browser :-}
This doesn't exhaust MSIE's misbehaviours by any means, but at least
it shows two clear violations of unequivocal mandatory requirements of
the interworking protocols.
hope this helps.
------------------------------
Date: Sun, 14 Aug 2005 17:34:54 +0200
From: Kornelis <k.p.boomsma@xs4all.nl>
Subject: Re: OT basic cgi button question
Message-Id: <42ff61e3$0$11077$e4fe514c@news.xs4all.nl>
Gunnar Hjalmarsson wrote:
> Kornelis wrote:
>
>> I would like to know why sending and retrieving a value with cgi
>> code like
>>
>> <button type="submit" name="show" value="y"> show </button>
>>
>> and
>>
>> if ($show eq "y") {
>> print qq| test ie: show eq y.... |;
>> }
>>
>> works fine in firefox, mozilla or konqueror, but does nothing at all
>> in internet explorer.
>
>
> If you try this script in Explorer, you'll notice that it submits
> something, but not what you told it:
>
> #!/usr/bin/perl
> print "Content-type: text/html\n\n";
>
> my $q = $ENV{QUERY_STRING};
> print "<pre>$q</pre>\n" if $q;
>
> print <<FORM;
> <form action="test.pl">
> <button type="submit" name="show" value="y"> click </button>
> </form>
> FORM
>
> __END__
>
> But if you want to know _why_, please ask at http://www.microsoft.com/
>
> Until they answer, why don't you just use
>
> <input type="hidden" name="show" value="y">
> <input type="submit" value=" show ">
>
Thank you. I will follow your advise. I started using the button tag because
it was an easy way to allow users to click for different options. I had no idea
that the button was unsupported, I thought I was missing something very basic.
------------------------------
Date: Sun, 14 Aug 2005 19:22:07 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: OT basic cgi button question
Message-Id: <3m9cu5F1652bjU1@individual.net>
Kornelis wrote:
> Gunnar Hjalmarsson wrote:
>> Until they answer, why don't you just use
>>
>> <input type="hidden" name="show" value="y">
>> <input type="submit" value=" show ">
>
> Thank you. I will follow your advise. I started using the button tag
> because
> it was an easy way to allow users to click for different options.
The input element is just as easy if you can live with values that equal
the button labels.
<input type="submit" name="color" value="Blue">
<input type="submit" name="color" value="Red">
<input type="submit" name="color" value="Green">
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 14 Aug 2005 15:31:16 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Probs with regex and nesting
Message-Id: <ddnkjl$uk5$1@redhat2.bham.ac.uk>
Gyruss wrote:
> Hi,
>
> I'm having trouble modifying the regular expression /^\{.*\}$/ so that a
> string with nested curly braces is deemed unmatched. E.g
>
> {recognizing syntax} - matched
> {recognizing syntax {foo} bar} - unmatched.
> {recognizing syntax {foo{ foo bar}} {bar}} - unmatched.
>
> Can this be done?
Can your criteria be expressed as "a string containing another '{'
character is unmatched?" (If not how are your criteria different).
/^{[^{]*}$/
------------------------------
Date: Sun, 14 Aug 2005 17:07:54 +0200
From: Christian Sengstock <sengc#rm_me#@web.de>
Subject: test if entry in hash ref is an array or a string?
Message-Id: <ddnmo7$h57$1@news.urz.uni-heidelberg.de>
Hi,
i want to get the value(s) of an hash ref which are either in an array
or it's just a string. How can i check this (with use strict)? Because
when i read the value like this:
@myArr = @{$aHashRef->{'anEntry'}};
i get the following error if anEntry is a string and not an array of
strings:
Can't use string ("aStringValue") as an ARRAY ref while "strict refs" in
use at file.pl ...
More concrete my problem goes like that:
i parse the entry of a xml file into a hash ref with xml:simple xmlin().
In the resulting hash ref i have either an array or a string
...
'entry1' => {
'val' => '123',
'inhgroup' => [
'grp1',
'grp2',
'grp3',
'grp4'
]
},
'entry2' => {
'val' => '456',
'inhgroup' => 'grp1'
},
...
At the moment i copy the array of the hash ref like this...
my @inhgroup = @{$xmlconfig->{$entryArr[$myEntry]}->{'inhgroup'}};
Is there a nicer way to access the values of an hash ref, and a more
flexible way according to the variable types?
Thanks, Chris
------------------------------
Date: Sun, 14 Aug 2005 12:04:27 -0400
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: test if entry in hash ref is an array or a string?
Message-Id: <eYJLe.2573$kz6.79818@news20.bellglobal.com>
"Christian Sengstock" <sengc#rm_me#@web.de> wrote in message
news:ddnmo7$h57$1@news.urz.uni-heidelberg.de...
> Hi,
> i want to get the value(s) of an hash ref which are either in an array or
> it's just a string. How can i check this (with use strict)? Because when i
> read the value like this:
>
> @myArr = @{$aHashRef->{'anEntry'}};
>
> i get the following error if anEntry is a string and not an array of
> strings:
>
> Can't use string ("aStringValue") as an ARRAY ref while "strict refs" in
> use at file.pl ...
>
>
perldoc -f ref
(see also perlref)
Matt
------------------------------
Date: Sun, 14 Aug 2005 20:33:20 +0200
From: Christian Sengstock <sengc#rm_me#@web.de>
Subject: Re: test if entry in hash ref is an array or a string?
Message-Id: <ddo2ou$jtm$1@news.urz.uni-heidelberg.de>
Matt Garrish schrieb:
> "Christian Sengstock" <sengc#rm_me#@web.de> wrote in message
> news:ddnmo7$h57$1@news.urz.uni-heidelberg.de...
>
>>Hi,
>>i want to get the value(s) of an hash ref which are either in an array or
>>it's just a string. How can i check this (with use strict)? Because when i
>>read the value like this:
>>
>>@myArr = @{$aHashRef->{'anEntry'}};
>>
>>i get the following error if anEntry is a string and not an array of
>>strings:
>>
>>Can't use string ("aStringValue") as an ARRAY ref while "strict refs" in
>>use at file.pl ...
>>
>>
>
>
> perldoc -f ref
>
> (see also perlref)
>
> Matt
>
>
... i think what i really need is a function like isarray(), which tells
me if the data i access via a hash reference is an array or not. Does
such a function, or a module providing such possibilities exist?
In general i'm interested in common techniques how to acces a unknown
hash reference. I think this problem is quite common so maybe there is a
modul and/or a tutorial about that (which i can't find).
Thanks, Chris
------------------------------
Date: Sun, 14 Aug 2005 20:50:33 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: test if entry in hash ref is an array or a string?
Message-Id: <3m9i3vF15n7f7U1@individual.net>
Christian Sengstock wrote:
> Matt Garrish schrieb:
>>
>> perldoc -f ref
>
> ... i think what i really need is a function like isarray(), which tells
> me if the data i access via a hash reference is an array or not.
I think that what you really need is taking the time to study the docs
that Matt pointed you to.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 14 Aug 2005 21:01:00 +0200
From: Christian Sengstock <sengc#rm_me#@web.de>
Subject: Re: test if entry in hash ref is an array or a string?
Message-Id: <ddo4cq$k8d$1@news.urz.uni-heidelberg.de>
Gunnar Hjalmarsson schrieb:
> Christian Sengstock wrote:
>
>> Matt Garrish schrieb:
>>
>>>
>>> perldoc -f ref
>>
>>
>> ... i think what i really need is a function like isarray(), which
>> tells me if the data i access via a hash reference is an array or not.
>
>
> I think that what you really need is taking the time to study the docs
> that Matt pointed you to.
>
ok i'm sorry!! i should have looked for that.
the ref() function is exactly what i was looking for
ref( $myhash{$entry} )
returns the datatype if $myhash($entry) is a reference.
thank, Chris
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8322
***************************************
