[19273] in Perl-Users-Digest
Perl-Users Digest, Issue: 1468 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 8 18:10:40 2001
Date: Wed, 8 Aug 2001 15:10:18 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <997308617-v10-i1468@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 8 Aug 2001 Volume: 10 Number: 1468
Today's topics:
newbie q: multi line matching <andy.piper@freeuk.com>
Re: newbie q: multi line matching (Tad McClellan)
Re: newbie q: multi line matching <andy.piper@freeuk.com>
newbie question... <leary@foad.NOSPAM.org>
Re: newbie question... <bkimelman@xxx.vzavenue.net>
Re: newbie question... <Tassilo.Parseval@post.rwth-aachen.de>
Re: newbie question... (Tad McClellan)
Re: Not matching strings nobull@mail.com
Re: Not matching strings <ren@tivoli.com>
Re: Perl & Cookies <gnarinn@hotmail.com>
Re: Perl not releasing lock on file under Windows?? (JR)
Re: perldoc is like Greek to a beginner?? <mjcarman@home.com>
Re: perldoc is like Greek to a beginner?? (Tad McClellan)
Re: q: converting strings (Tad McClellan)
Re: q: converting strings (Tad McClellan)
Redirect Script with Form Variables <here@there.com>
Re: RegEXP's (Tad McClellan)
Re: Reporting Questionable Programming Activity slash@dot.c.o.m.org
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 08 Aug 2001 22:03:32 +0100
From: "Andy Piper" <andy.piper@freeuk.com>
Subject: newbie q: multi line matching
Message-Id: <20010808.220330.1884661237.2466@freeuk.com>
Hi,
I'm new to the Perl language, and at the moment it feels a lot like I've
bitten off more than I can chew :-/
I've got a file which I know contains a number of lines of a particular
format, with three variations:
1)
mystring1
2)
mystring1 string2
3)
mystring1 string2
string3
I want to be able to count all lines beginning with "mystring1" (easy),
and then count all occurences of 2), excluding 3) - that is, "mystring1
string2<CR><blank line or CR>" not "mystring1 string2<CR>string3".
At present a friend has helped me to the following, but it is flawed - my
fault, not his - as it counts cases 1) plus 2) AND 3), which is no good. I
believe I need to be able to perform multiline match, but I can't figure
out how to achieve that :-(
open INPUT, "<$i" or die "Can't open $i";
while (<INPUT>)
{
$counter1++ if $_ =~ /^mystring1/;
$counter2++ if $_ =~ /^mystring1 string2"/;
# unfortunately matching "mystring1 string2\n\n" doesn't work :-(
}
Any help would be appreciated :-)
--
Andy Piper - Fareham, Hampshire (UK)
andy.piper@freeuk.com - ICQ #86489434
http://www.andypiper.co.uk/
------------------------------
Date: Wed, 8 Aug 2001 16:41:15 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: newbie q: multi line matching
Message-Id: <slrn9n38vb.nsv.tadmc@tadmc26.august.net>
Andy Piper <andy.piper@freeuk.com> wrote:
>
>I've got a file which I know contains a number of lines of a particular
^^^^^
>format, with three variations:
That can't be right. There are only 2 variations of lines below.
You must have meant "records" instead.
>1)
>mystring1
>
>2)
>mystring1 string2
>
>3)
>mystring1 string2
>string3
>
>I want to be able to count all lines beginning with "mystring1" (easy),
>and then count all occurences of 2), excluding 3) - that is, "mystring1
>string2<CR><blank line or CR>" not "mystring1 string2<CR>string3".
^^ ^^ ^^
^^ ^^ ^^
So you are on a Mac then?
Assuming the Whole Darn File is in $_:
$count++ while /^mystring1.*\n\n/gm;
>I
>believe I need to be able to perform multiline match, but I can't figure
>out how to achieve that :-(
Even before that, you need to figure out how to _get_ a mutliline
string to match against in the first place.
Your code below never has more than a single line in $_.
> open INPUT, "<$i" or die "Can't open $i";
one-character variable names suck.
> while (<INPUT>)
> {
> $counter1++ if $_ =~ /^mystring1/;
> $counter2++ if $_ =~ /^mystring1 string2"/;
> # unfortunately matching "mystring1 string2\n\n" doesn't work :-(
> }
>
>Any help would be appreciated :-)
open INPUT, $filename or die "Can't open '$filename' $!";
{ local $/; # enable slurp mode
$_ = <INPUT>; # slurp entire file into a single scalar
}
close(INPUT);
# pattern match as above...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 08 Aug 2001 23:03:22 +0100
From: "Andy Piper" <andy.piper@freeuk.com>
Subject: Re: newbie q: multi line matching
Message-Id: <20010808.230321.1884661237.7875@freeuk.com>
In article <slrn9n38vb.nsv.tadmc@tadmc26.august.net>, "Tad McClellan"
<tadmc@augustmail.com> wrote:
> Andy Piper <andy.piper@freeuk.com> wrote:
>>
>>I've got a file which I know contains a number of lines of a particular
> ^^^^^
>>format, with three variations:
>
> That can't be right. There are only 2 variations of lines below.
> You must have meant "records" instead.
Sorry, yes - in the context of single or multiple lines. I should have
chosen my words more carefully :-)
[snip]
>>I want to be able to count all lines beginning with "mystring1" (easy),
>>and then count all occurences of 2), excluding 3) - that is, "mystring1
>>string2<CR><blank line or CR>" not "mystring1 string2<CR>string3".
> ^^ ^^ ^^ ^^
> ^^ ^^
>
> So you are on a Mac then?
Actually no :-)
Again, using <CR> was a bit misleading, sorry - it was only intended as an
example. I should probably have just gone for "newline", it's more
neutral!
> Assuming the Whole Darn File is in $_:
>
> $count++ while /^mystring1.*\n\n/gm;
Ah. I did play with this "slurp mode" - using $/ - but I had gone about
it in the wrong way in my experiments. Thanks for the illustration.
>> while (<INPUT>)
>> {
>> $counter1++ if $_ =~ /^mystring1/;
>> $counter2++ if $_ =~ /^mystring1 string2"/; # unfortunately
>> matching "mystring1 string2\n\n" doesn't work :-(
>> }
>
> open INPUT, $filename or die "Can't open '$filename' $!";
> { local
> $/; # enable slurp mode
> $_ = <INPUT>; # slurp entire file into a single scalar
> }
> close(INPUT);
>
> # pattern match as above...
Ah, but now how do I get the count of the number of lines starting just
with "mystring" (equivalent to my original $counter1)? The way I've
rather hurriedly chosen is to open INPUT twice: firstly, loop round in
exactly the same way as before and increment $counter1, and then close;
secondly, go around the loop you've suggested with the pattern match on
the slurped file. Surely that's not the most elegant way... apart from
anything else, it involves two lots of I/O per file.
Thanks for the advice, Tad - I'm learning, gradually...
--
Andy Piper - Fareham, Hampshire (UK)
andy.piper@freeuk.com - ICQ #86489434
http://www.andypiper.co.uk/
------------------------------
Date: Wed, 8 Aug 2001 13:55:42 -0500
From: "Leary" <leary@foad.NOSPAM.org>
Subject: newbie question...
Message-Id: <Iigc7.4771$V43.379193@e3500-atl1.usenetserver.com>
Why does the snippet below not work? If I comment out either of the system()
calls the script works fine. But if both lines are active I geta syntax
error.
TIA
#!perl -w
# 8/8/2001 12:56PM
system("vhouse3 %IBERDIR%\\data\\house50 > house50.txt")
system("dbf2text %IBERDIR%\\data\\hse.dbf hsedbf.txt")
------------------------------
Date: Wed, 8 Aug 2001 15:12:25 -0500
From: Barry Kimelman <bkimelman@xxx.vzavenue.net>
Subject: Re: newbie question...
Message-Id: <MPG.15db5928226efe01989683@east.usenetserver.com>
In article <Iigc7.4771$V43.379193@e3500-atl1.usenetserver.com>,
leary@foad.NOSPAM.org says...
> Why does the snippet below not work? If I comment out either of the system()
> calls the script works fine. But if both lines are active I geta syntax
> error.
>
> TIA
>
> #!perl -w
> # 8/8/2001 12:56PM
> system("vhouse3 %IBERDIR%\\data\\house50 > house50.txt")
>
> system("dbf2text %IBERDIR%\\data\\hse.dbf hsedbf.txt")
>
>
>
>
>
All perl statements must be terminated by a semicolon
---------
Barry Kimelman
Lewisville, TX, USA
email : bkimelman@hotmail.com
------------------------------
Date: Wed, 08 Aug 2001 22:38:17 +0200
From: Tassilo von Parseval <Tassilo.Parseval@post.rwth-aachen.de>
Subject: Re: newbie question...
Message-Id: <3B71A339.4050106@post.rwth-aachen.de>
Barry Kimelman wrote:
> All perl statements must be terminated by a semicolon
Strictly speaking, this is not quite true. The semicolon in Perl rather
acts like a statement delimiter than a terminator. That's why
if ($cond) { print "hello" }
works.
Tassilo
--
$a=[(74,116)];$b=[($a->[1]-1,$a->[1]++,0x20)];$c=[(97,110)];$d=[($c->
[1]+1,$b->[1],"her")];for(@{[$a,$b,$c,$d]}){for(@{$_}){$_=~/\d+/?print
(chr($_)):print;}}$c=sub{$l=shift;[(0x20+$l-1,0x50,0x65,0x73-0x01,108
),(0x20,0x68,0x61,)]};print(map{chr($_)}@{($c->(1))});$h={a=>33*3,b=>
10**2+7,c=>"1"."0"."1",d=>0162};@h=sort(keys(%$h));for(@h){print(chr(
ord(chr($h->{$_}))))};
------------------------------
Date: Wed, 8 Aug 2001 16:09:41 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: newbie question...
Message-Id: <slrn9n3745.np3.tadmc@tadmc26.august.net>
Barry Kimelman <bkimelman@xxx.vzavenue.net> wrote:
>All perl statements must be terminated by a semicolon
^^^
^^^
No they don't:
------------
#!/usr/bin/perl -w
use strict;
print "Hello world with no semicolon\n"
------------
Works fine.
Semicolon is NOT a "statement terminator" in Perl (as it is in C, Java...).
Semicolon is a "statement separator" in Perl.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 8 Aug 2001 12:57:45 -0700
From: nobull@mail.com
Subject: Re: Not matching strings
Message-Id: <4dafc536.0108081157.567266c2@posting.google.com>
Jasper McCrea <jasper@guideguide.com> wrote in message news:<3B714A08.BC2C7D5E@guideguide.com>...
> Jasper McCrea wrote:
> >
> > Grunge Man wrote:
> > >
> > > Is there are method of not matching a pattern in an entire
> > > line without using !~
> > >
> > > if ($string =~ /^(?:(?!PAT)|.)*$/) {
> > > print "hi\n";
> > > }
> sorry, didn't really read that. If you're determinded to use =~, use
> unless
>
> print "hi\n" unless $string =~ /^PAT$/;
Ho, ho, very funny.
print "hi\n" if $string =~ /^(?!.*PAT)/;
Of course this is not efficient and like I always say to people who
ask this question here my spider sense tells me you really need to
learn about code references.
------------------------------
Date: 08 Aug 2001 14:36:04 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: Not matching strings
Message-Id: <m3vgjycpjv.fsf@dhcp9-161.support.tivoli.com>
On 8 Aug 2001, grunge12345@hotmail.com wrote:
> Is there are method of not matching a pattern in an entire
> line without using !~
>
> if ($string =~ /^(?:(?!PAT)|.)*$/) {
> print "hi\n";
> }
>
> will print hi whenever PAT doesn't occur anywhere in the string,
> but it also fails for lines like "asdfPATzxcv".
I'm not sure what you think that does, but it matches any string.
> i.e. Is there a way of doing:
>
> if ($string !~ /^PAT$/) {
> print "hi\n";
> }
>
> but using =~ instead of !~
Assuming that simply negating the result of the match as others have
already suggested is not sufficient, perhaps you are striving for:
if ($string =~ /^(?!.*PAT)/) {
print "hi\n";
}
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: Wed, 8 Aug 2001 18:01:07 +0000
From: gnari <gnarinn@hotmail.com>
Subject: Re: Perl & Cookies
Message-Id: <997293667.324500857852399.gnarinn@hotmail.com>
In article <9krbfb$sol$1@neptunium.btinternet.com>,
Jeff Snoxell <Jeff@aetherweb.co.uk> wrote:
>
>How can I use perl/cgi to get and set cookies (all from one domain name)
>which can be read from various pages within my domain. I've read, in the
>unofficial cookie FAQ here...http://www.cookiecentral.com/faq/#3.2, that
>cookies are stored on a per document basis, and only that document can
>access the cookie again.... but it also says that to test if a client can
>access cookies, I should set a cookie on one page, and test it on another.
>
>I want to keep track of a user while they're at my site, regardless of the
>page.
>
this is not on-topic in this newsgroup as this is not a perl question
but you have misunderstood something. cookies are NOT stored on a per
document basis. the section you quoted does not claim that either.
gnari
------------------------------
Date: 8 Aug 2001 13:57:07 -0700
From: tommyumuc@aol.com (JR)
Subject: Re: Perl not releasing lock on file under Windows??
Message-Id: <319333f5.0108081257.1963e751@posting.google.com>
Carlos C. Gonzalez <miscellaneousemail@yahoo.com> wrote in message news:<MPG.15d7924481656b7d989707@news.edmonton.telusplanet.net>...
> Hi everyone,
>
> I have a CGI Perl script activated by a submit button on an HTML form.
> The CGI script executes fine under Perl at the DOS command prompt.
>
> This is the code (it's just a dummy script to test that things are
> working):
>
> #!/usr/bin/perl
>
> use CGI::Carp qw(carpout fatalsToBrowser);
> use diagnostics;
> use strict;
>
> use constant TRUE => "1"; #any value other than "0" or "" is
> true!
> use constant FALSE => "0";
>
> print "Content-type: text/html\n\n";
>
> if ("1" eq TRUE) {
> print "hello there";
> }
>
> When I run this CGI script as the action of my HTML form my browsers
> (both Opera and Internet Explorer) pass off control to the Perl
> interpreter. At this point Perl apparently gets stuck and never closes
> down. The CGI file ends up being locked and I am denied access and must
> jump through hoops to be able to edit it again.
>
> In the CTRL-ALT-DEL windows box Perl shows up for as many times as I have
> pressed the Subscribe button on my form (calling the CGI script above in
> the process). I have to End Task each instance of Perl manually before I
> stand a chance of editing and saving changes to my CGI script again.
>
> Has anyone ever experienced something like this before? If so can you
> share what the cause and solution was?
>
> I am running Windows Apache and serving up the HTML form and calling the
> CGI script through localhost. I have done this a lot and have not
> experienced this problem before.
>
> Thanks.
Point your test html document to this script, and click submit---
############
#You may have to modify the first line of this script...
#!/usr/local/bin/perl5 -w
use Fcntl qw(:flock);
use CGI qw(:all);
use CGI qw(:all escape);
use CGI::Carp qw(fatalsToBrowser);
use strict;
use diagnostics;
my $q = new CGI;
print header;
print "Hello, World!\n";
############
Does this give you the expected output of "Hello, World!," or does
this also hang? I've experience CGI script hanging for apparently no
reason, and I don't see any reason why your test script should hang or
give you the problems you described. I never use print "Content-type:
text/html\n\n"--I use "print header" instead, so maybe that will make
a difference. Good luck with getting your problem resolved.
------------------------------
Date: Wed, 08 Aug 2001 12:57:48 -0500
From: Michael Carman <mjcarman@home.com>
Subject: Re: perldoc is like Greek to a beginner??
Message-Id: <3B717D9C.3F442922@home.com>
"Carlos C. Gonzalez" wrote:
>
> In article <slrn9n2gsj.mbp.tadmc@tadmc26.august.net>, Tad McClellan
> at tadmc@augustmail.com says...
>>
>
> As another example of the kind of confusion that Perl can be for a
> beginning Perl programming take regular expressions.
Regexes are really their own seperate language. It just happens that
regex support is built in to Perl. It might help your sanity if you can
mentally partition the two.
> Sure an assignment operation such as $string = "some value" is a
> programming fundamental.
>
> But not something like: $pattern =~ s/(\W)/\\$1/g;. This is Perl
> peculiar. At least from my background. I've never had to deal with
> this kind of confusing string until arriving at Perl.
It's your background. Larry borrowed the best points from lots of
different places when creating Perl -- very little of it is unique.
Because of this, almost everybody can find something familiar about
Perl, as well as something unfamiliar. In this case, regexes come from
Unix. (I first came across s/// in vi.)
>> Learning programming AND Perl at the same time will be much much
>> harder than learning either one by itself.
>
> Agreed. But again I wonder if learning programming is the issue
> here. Take any top notch Delphi object oriented programmer and
> throw him or her into Perl and see what happens.
There's always some pain in adjusting to a new mindset. Try alternating
between Perl and Ada if you want to see frustration...
> A few times in this newsgroup I have been led to believe that if
> I had only read the documentation I would not have needed to ask
> a question (even though I have spent on average of about an hour
> searching and reading through stuff or trying code for every
> question I ask).
The reason you got responses like that is that most posters don't check
the docs first. In the future, just say "I read the perlxxx manpage, but
I'm still confused." If you can show that you've tried to help yourself
before appealing to Usenet, you'll avoid those RTFM answers.
> I am very appreciative of the help I have been given here but I
> would definitely tell newbie Perl programmers (from whatever
> background) to tread lightly here and to make sure that they
> have done some homework. Which is a good thing I guess.
It's a very good thing, and all we really ask for. :)
-mjc
------------------------------
Date: Wed, 8 Aug 2001 15:28:16 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: perldoc is like Greek to a beginner??
Message-Id: <slrn9n34mg.nit.tadmc@tadmc26.august.net>
Carlos C. Gonzalez <miscellaneousemail@yahoo.com> wrote:
>In article <slrn9n2gsj.mbp.tadmc@tadmc26.august.net>, Tad McClellan at
>tadmc@augustmail.com says...
>
>> >> Interpolation, unary operator, lexical scope, expected semantics, extent
>> >> of a string... These are just some of the "Greek" terms in perldoc
>> >> perlop that I saw.
>>
>>
>> Each of those terms (except perhaps interpolation) will be familiar
>> to anyone who has the fundamentals of programming in general.
>>
>
>Hi Tad and everyone else. Thanks for all your input. I am not sure I
>agree with the statement that the "terms will be..." above.
[snip: learned programming from OJT rather than formal training ]
>> As Eric has mentioned, the Perl docs should document Perl. Other
>> docs should document programming fundamentals.
>
>If by programming fundamentals you mean control structures, compiling
>verses interpretation, structure programming verses objection oriented
>programming, using control structures like while and if statements, I
>completely agree.
Yes, all of those would be "fundamentals" in my book, but so
would "unary operator", "semantics" etc...
>As another example of the kind of confusion that Perl can be for a
>beginning Perl programming take regular expressions.
This is not Perl being confusing, this is regular expressions
being confusing.
Would Perl be less confusing without builtin support for regexs?
Sure it would (it would also be vastly less useful, everything
is a trade-off).
>I have never in my
>life had to deal with the confusions of Perl regular expressions.
^^^^
Have you dealt with the confusions of non-Perl regular expressions before?
I'm wondering why the qualifying "Perl" is there?
_All_ regular expression languages are confusing in my experience.
>C came
>close but even in C they were logical and from what I remember the
>characters used were consistent.
C does not have native support for regexs, so I'm not sure
what you are referring to there...
>They did not change much with the
>context. One character did not mean one thing until it was put inside
>brackets to mean something else type of thing. And C's regular
^^^^^^^^^^^
>expressions did not have the incredibly rich set of possibilities that
^^^^^^^^^^^
>Perl's does IMHO.
What are "C's regular expressions"?
>Perl's regular expressions seem to be so much more powerful and this is a
>very good thing. But all the symbols and their combined uses takes a bit
>to get used to.
Power has its price.
>Try writing Perl like regular
>expression in Delphi or Visual Basic?
Do those languages have native regular expressions?
I've not used either.
I would be interested to know how they differ from Perl's.
>You'll have to bend all over the
>place if you can even do it.
So it sounds like those languages do _not_ have native regexs.
Then it can be summed up:
Pattern matching cannot be done in VB/Delphi, but what _can_
be done is easy to understand.
Pattern matching can be done in Perl, but it is hard to understand.
I prefer "possible but hard" to "impossible" :-)
>More than likely you will have to use a
>bunch of if statements to accomplish the same thing that can be done in
>Perl with one line.
Power has its price.
>I certainly wouldn't call regular expressions
>something that is a programming fundamental.
Regular grammars are certainly a programming fundamental.
Regular expressions correspond to regular grammars.
I guess we will have to agree to disagree on the value of
parsing/machine language theory.
>At least in how Perl does
>it. Perl regular expressions are a skill all on it's own IMHO.
Yes. Power has its price.
>Sure an assignment operation such as $string = "some value" is a
>programming fundamental.
>
>But not something like: $pattern =~ s/(\W)/\\$1/g;. This is Perl
>peculiar.
Of course Perl's _operators_ are peculiar to Perl.
But we are talking about regular expressions, not operators
that use them.
(\W)
is the regular expression in the above. You picked a
not-very-complicated regex as an example of a complicated
regex :-)
>At least from my background. I've never had to deal with this
>kind of confusing string until arriving at Perl.
So how have you done complicated pattern matching in the past then?
If there is an easier way, I'd like to know about it.
Regular expressions have been around in pretty much the same
form for over 20 years.
Everybody knows that they look ugly.
If there was a "better way", someone would have found it by now.
It is the "nature of the beast" that pattern matching code is
hard to read. Nothing to do with Perl.
Power has its price.
>> Learning programming AND Perl at the same time will be much much
>> harder than learning either one by itself.
>
>Agreed. But again I wonder if learning programming is the issue here.
I think perhaps we associate different things with the term
"programming".
I think I mean "computer science" when I say "programming fundamentals".
I think you mean "can write complicated programs that work correctly".
>Take any top notch Delphi object oriented programmer and throw him or her
>into Perl and see what happens. Some might not even survive. Visual
>Basic programmers would even fare worse I think.
Well yes. Formal training must have some benefit, or there wouldn't
be so many people taking it :-)
>Maybe
>their background is not a four year degree in computer science but I
>would still call them programmers though not neccessarily computer
>scientists. At least IMHO.
Aha. We _are_ speaking of different things, as I just described above.
>> >Just note that no one is frowning upon people not yet fully
>> >understanding the perl documentations. Just disregarding them at all is
>> >considered a major sin in this newsgroup. ;-)
>
>I've sort of discovered that already. A few times in this newsgroup I
>have been led to believe that if I had only read the documentation I
>would not have needed to ask a question (even though I have spent on
>average of about an hour searching and reading through stuff or trying
>code for every question I ask). At least that was the implication in
>some of the responses.
This is a programming newsgroup. A background in the fundamentals
is assumed. If the "standard assumption" does not apply to you,
you'll need to tell us, we can't know what you know.
If you come back after RTFMing and say:
I don't get what "lexical scope" means.
You should be able to get a polite explanation (or silence, you
take your chances on getting any reply at all on Usenet).
>To be sure most responses have been absolutely
>wonderful but a few of them have led me to be very careful in asking
>questions on this newsgroup.
Good. I imagine we'd have 700 messages a day here without
the "curbing" that you mention :-)
Even with our curmudgeonliness, we _still_ get too much traffic here.
>Sometimes I feel like I am talking to
>programmers who have lost touch with the realities of first coming into
>Perl.
This can (and does) surely happen.
All we can do is try and recognize it, and jerk ourselves back.
Sometimes we fail. (it is rumored that we are humans)
>Please don't take any of this to mean that I do not respect the responses
>or anyone in particular.
And do not get the idea from my responses here that I think Perl is "easy".
PHIP (I'm sure you can expand that by now :-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 8 Aug 2001 13:17:54 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: q: converting strings
Message-Id: <slrn9n2t22.n5u.tadmc@tadmc26.august.net>
Oliver <ow22@nospam-cornell.edu> wrote:
>how do i convert a string to an int? thanks
Why do you think that you need to convert a string to an int?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 8 Aug 2001 13:40:13 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: q: converting strings
Message-Id: <slrn9n2ubt.n9n.tadmc@tadmc26.august.net>
Jasper McCrea <jasper@guideguide.com> wrote:
>Malcolm Dew-Jones wrote:
>>
>> Oliver (ow22@nospam-cornell.edu) wrote:
>> : how do i convert a string to an int? thanks
>>
>> In perl, if the string looks like a number then it is a number.
>>
>
>This is a little misleading.
Not nearly as misleading, IMO, as your comments that follow...
>$one = "twelve";
>$two = "12";
>
>both are strings, and look like numbers to me.
^^^^^
I suggest that perhaps you are in the minority then.
I think most folks could see the second one as a number,
but not the first one.
>It is when perl comes to interpret a string as a number that it does
>some fancy stuff. If you int(), even indirectly, a string that has no
^^^^^
We are not speaking of "forcing to integer" here. We are talking
about automatic conversion of strings to numbers, which applies
to floats as well as integers.
>leading number characters, it'll give you zero, and work with that.
>print "twelve" + "thirteen", "\n"; # gives 0
>print "this12" + "that13", "\n"; # gives 0
What do you say it _should_ give instead then?
Zero seems a reasonable choice, given the nonsensical notion of
"adding strings".
Addition is defined for numbers. If you don't have numbers, then
you don't know what "addition" means.
>print "same string\n" if "13this" eq "13that"; # doesn't print
>print "same number\n" if "13this" == "13that"; # does print
That won't confuse anyone with the least little bit of sense,
because they will have warnings enabled and the warning will
point out that something is "wrong" with the 2nd one above.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 8 Aug 2001 14:27:59 -0500
From: "Peter" <here@there.com>
Subject: Redirect Script with Form Variables
Message-Id: <Yogc7.6767$pH1.55267@news1.mts.net>
I'm looking for a redirect script that will allow me to send variables from
a form which a user fills in on a web page, to another URL. So the action
line of the form would have the URL of this cgi script, and when the user
clicks the submit button all the variables of the form are sent to the
redirected page. The script itself does not need to read and use the
variables, just pass them along. Anyone know where I could find such a
script?
Thanks in advance.
Peter
------------------------------
Date: Wed, 8 Aug 2001 13:43:49 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: RegEXP's
Message-Id: <slrn9n2uil.n9n.tadmc@tadmc26.august.net>
Gary E. Ansok <ansok@alumni.caltech.edu> wrote:
>In article <9krjeu$64vma$1@ID-17302.news.dfncis.de>,
>Adrian Immler <newsgroup@12mm.de> wrote:
>>$array[n] = '<a
>>href="http://www.foo-bar.com/index.php?action=listall&user=foo">';
>>i've got the problems with that it should not break it up at spaces within
>><>.
>
>I think
Why not execute it and _know_?
Test data was supplied...
>this would do what you're asking for:
>
>@array = $string =~ m/<.*?>|[^\s<]+/g;
That will not work for the snippet of HTML quoted above, and
provided in the original post. You are missing an 's' option.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 08 Aug 2001 22:02:38 GMT
From: slash@dot.c.o.m.org
Subject: Re: Reporting Questionable Programming Activity
Message-Id: <3b71b6d5.9344968@news.freeserve.co.uk>
On Tue, 31 Jul 2001 21:31:28 GMT, gurm@intrasof.com (Smiley) wrote:
>The company I'm working for purchased a Perl CGI Script that turns out
>to be seriously faulty - so much so that my boss asked me to
>investigate whether there's any international agency or organization
>set up that we can report this kind of thing to.
If the software is unfit for the use for which it's being sold, then return it and
claim a refund.
------------------------------
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 1468
***************************************
