[10946] in Perl-Users-Digest
Perl-Users Digest, Issue: 4547 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jan 4 20:27:17 1999
Date: Mon, 4 Jan 99 17:05:29 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 4 Jan 1999 Volume: 8 Number: 4547
Today's topics:
parse question <peter.furmonavicius@yale.edu>
Re: parse question <jdf@pobox.com>
Re: parse question (Greg Bacon)
Re: Path under windows (Clinton Pierce)
Re: Path under windows <jwarner@tivoli.com>
Re: Path under windows <jwarner@tivoli.com>
Perl 5 for NT: How to do an End Process on a deadlocked <caitlin@nospam.backstreet.net>
Re: Perl 5 for NT: How to do an End Process on a deadlo <dgris@moiraine.dimensional.com>
Perl file handling <regevs@mishkei.org.il>
Re: Perl file handling <uri@ibnets.com>
Re: Perl file handling (Martien Verbruggen)
Re: Perl Scripts on NT with Sounds <ibelgaufts@gfc-net.de>
perlcc compiling to bytecode <admin@oneseek.com>
Please Help!! Surgeman@concentric.net
Re: Please Help!! <staffan@ngb.se>
Re: Please Help!! (Martien Verbruggen)
Re: Please Help!! <eugene@verticalnet.com>
Problems with Win32::API <ibelgaufts@gfc-net.de>
Re: Programming Rules in Perl (Bob Dubery)
Re: Programming Rules in Perl <tchrist@mox.perl.com>
Re: Programming Rules in Perl <ebohlman@netcom.com>
Re: READDIR doesn't work (Tad McClellan)
Re: Reading comma delimited files (Burt Lewis)
Re: Reading comma delimited files <grimes@waste.org>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 04 Jan 1999 17:12:13 -0500
From: Peter Furmonavicius <peter.furmonavicius@yale.edu>
Subject: parse question
Message-Id: <peter.furmonavicius-040119991712135927@peter.cis.yale.edu>
Happy New Year. Can anyone show me the neatest, most elegant way to
parse lines of test that have fields delimited by commas, except that
some of the fields might be double-quoted and contain commas within
them? An example line might be:
1,2,"Furmonavicius, Peter",3,4, etc.
I would want field one to be: 1
field two to be: 2
field three to be: Furmonavicius, Peter
field four to be: 3
etc.
I can write code to do this, and already have. But I was just curious
to see what a top-notch, regular expression, Perl guru would come up
with. Thanks in advance.
------------------------------
Date: 05 Jan 1999 00:14:37 +0100
From: Jonathan Feinberg <jdf@pobox.com>
To: Peter Furmonavicius <peter.furmonavicius@yale.edu>
Subject: Re: parse question
Message-Id: <m367amtyua.fsf@joshua.panix.com>
Peter Furmonavicius <peter.furmonavicius@yale.edu> writes:
> 1,2,"Furmonavicius, Peter",3,4, etc.
> I can write code to do this, and already have. But I was just curious
> to see what a top-notch, regular expression, Perl guru would come up
> with. Thanks in advance.
A Perl guru would exercise wisdom by considering the existing CSV
modules, which are available at the CPAN.
# perl -MCPAN -e shell
cpan> i /csv/
--
Jonathan Feinberg jdf@pobox.com Sunny Brooklyn, NY
http://pobox.com/~jdf
------------------------------
Date: 4 Jan 1999 23:02:59 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: parse question
Message-Id: <76rhb4$84j$1@info.uah.edu>
In article <peter.furmonavicius-040119991712135927@peter.cis.yale.edu>,
Peter Furmonavicius <peter.furmonavicius@yale.edu> writes:
: Happy New Year. Can anyone show me the neatest, most elegant way to
: parse lines of test that have fields delimited by commas, except that
: some of the fields might be double-quoted and contain commas within
: them? An example line might be:
:
: 1,2,"Furmonavicius, Peter",3,4, etc.
[snip]
: I can write code to do this, and already have. But I was just curious
: to see what a top-notch, regular expression, Perl guru would come up
: with. Thanks in advance.
Many people, most notably Tom Christiansen and Nathan Torkington, have
worked very hard to compile a wealth of the sort of top-notch guru code
that you desire. We lovingly refer to the product as the FAQ. The FAQ
is even included with the Perl distribution. You can find it on the
web. Failing to consult the wonderful FAQ before posting to machines
around the world is to throw a priceless resource in the trash.
Read the FAQ. I recommend reading straight through. The answer to your
particular question lies in Section 4.
Hope this helps,
Greg
--
I considered atheism but there weren't enough holidays.
------------------------------
Date: Mon, 04 Jan 1999 16:59:44 GMT
From: cpierce1@mail.ford.com (Clinton Pierce)
Subject: Re: Path under windows
Message-Id: <3694ef49.2418631354@news.ford.com>
[Courtesy CC sent to poster in E-Mail]
On 2 Jan 1999 15:04:58 -0000, Jonathan Stowe <gellyfish@btinternet.com>
wrote:
>On Sat, 02 Jan 1999 08:13:30 GMT Ethan H. Poole wrote:
>>
><snip>
>
>> My suggestion: write a thorough and universal parsing function and use it in
>> all your projects. The use of a consistent and well proven function will
>> save you a lot of development and debugging time down the road. In the
>> meantime, use the CGI.pm module available until you learn how to write these
>> functions for yourself.
>>
>
>Purely out of interest, given that we have CGI.pm why , unless motivated
>by curiosity or hubris, would anyone need to write their own Request
>parsing functions (of course I can see that there might arise a special
>need but I mean a general purpose routine here) ?
I'm not the original poster, but in my case...because I do contract work
for the occasional webmaster who runs IIS and has a
Microsoft-distributed Perl 5.003 (?) distribution which does not include
the CGI.pm modules.
Getting CGI.pm installed is not possible because that would require them
to create a subdirectory (Oooh! Ahhh!), and distribute two files when
only one is apparently necessary. Also, I have no way of testing the
CGI.pm installation. (I run UNIX, they run NT). They can't install the
module from CPAN, and since it's not Activestate they can't use PPM to
install it.
Can a UNIX CGI.pm (Perl 5.005) be lifted out of a UNIX distribution and
be put on an NT box (Perl 5.003)? Probably...maybe...Are there
dependancies that would need to get resolved?
Figuring out (at CGI runtime) where a locally installed CGI.pm isn't
much fun. (Thanks to the Perl Cookbook). Especially when the webmaster
just picks up the script referenced in the form, and moves it from
system...to system...
I roll my own because it's robust from an installation/distribution
point of view. Yes I steal code from CGI.pm, becuase I don't want to
completely re-invent the wheel, but I don't want phone calls because the
script broke when moved from system A to system B.
------------------------------
Date: Mon, 04 Jan 1999 15:37:20 -0600
From: John Warner <jwarner@tivoli.com>
Subject: Re: Path under windows
Message-Id: <36913490.54FB44CC@tivoli.com>
What version of CGI.pm were you using? Old versions of CGI.pm have had their
share of problems but I haven't encountered any problems with 2.36 or 2.46.
Under what conditions did you encounter slowness with CGI.pm? I like to use
CGI.pm and have always wondered about its performance under extreme load (several
hundred hits per second) but have never had a way to test it.
The first time I tried to use CGI.pm was on an NT 4 Workstation where I hadn't
realized that the ActiveState installer associated .pl with perl.exe. Using
perl.exe causes a HUGE performance hit on the server because NT has to load a
separate process space for each copy of perl.exe. Once I reconfigured things to
run under IIS using perlis.dll, CGI.pm was lightning fast because all my scripts
ran under a single process.
John Warner
"Ethan H. Poole" wrote:
> In article <76lciq$vi$1@gellyfish.btinternet.com>,
> gellyfish@btinternet.com says...
> >
> >On Sat, 02 Jan 1999 08:13:30 GMT Ethan H. Poole wrote:
> >>
> >Of course some object that CGI.pm is a little oversized for some purposes
> >but there are alternatives in the various CGI::* modules available.
> >I thought that the purpose of CPAN was to promote code reuse on the
> >grand scale.
>
> Speaking personally, I tend to prefer to use my own code (and be responsible
> for its maintenance and any future bugs... I hate depending on an external
> module only to have a new version released with a bug that makes it look like
> bad programming on my part <g>). It gives me total revision control (and a
> singular point of responsibility).
>
> As for my own avoidance of CGI.pm, the bloating is reason #1. I used the
> CGI.pm module back in my earlier days of learning Perl and found that
> virtually all my scripts spent more time loading and compiling just the
> CGI.pm module than they did compiling and executing my code, the performance
> hit just wasn't acceptable to me.
>
> But I do strongly encourage reuse of tested code for beginners, it saves
> people from a lot of "shooting oneself in the foot" scenerios! Even I use
> *some* CPAN modules, it really depends on whether I like the way they were
> implemented, their features, etc. If I don't like something, I just write my
> own.
>
> --
> Ethan H. Poole | Website Design and Hosting,
> | CGI Programming (Perl & C)..
> ========Personal=========== | ============================
> * ehpoole @ ingress . com * | --Interact2Day--
> | http://www.interact2day.com/
------------------------------
Date: Mon, 04 Jan 1999 15:50:51 -0600
From: John Warner <jwarner@tivoli.com>
Subject: Re: Path under windows
Message-Id: <369137BB.7E61D34@tivoli.com>
An interesting problem. Are you sure they can install the ActiveState build? It
certainly would make life easier. If you absolutely have to do this the hard way
there are a couple of approaches. First, if they have a C compiler on the machine,
have them download and install the CGI module off CPAN. The installation procedure
should be substantially similar to that used on Unix. If all else fails, you can
copy the .pm files from the distribution to replace the existing .pm files of the
same names. (Make a backup of your originals first!) I've installed modules both
ways. The second method is certainly harder because of the verification testing
needed to ensure the new .pm files are functioning properly.
One alternative I can think of right off is to install Timbuktu on both your Unix
box and their NT box. Although I haven't personally used it, I had a former
coworker who did use it between his Unix and NT boxes at work because he only had
space for a single monitor, k/b, and mouse.
However, the best advice is to have them upgrade to the ActiveState build. From
what you describe, your client also needs some educating about basic NT
operation/administration.
HTH,
John Warner
Clinton Pierce wrote:
> [Courtesy CC sent to poster in E-Mail]
>
> On 2 Jan 1999 15:04:58 -0000, Jonathan Stowe <gellyfish@btinternet.com>
> wrote:
> >On Sat, 02 Jan 1999 08:13:30 GMT Ethan H. Poole wrote:
> >>
> ><snip>
> >
> >> My suggestion: write a thorough and universal parsing function and use it in
> >> all your projects. The use of a consistent and well proven function will
> >> save you a lot of development and debugging time down the road. In the
> >> meantime, use the CGI.pm module available until you learn how to write these
> >> functions for yourself.
> >>
> >
> >Purely out of interest, given that we have CGI.pm why , unless motivated
> >by curiosity or hubris, would anyone need to write their own Request
> >parsing functions (of course I can see that there might arise a special
> >need but I mean a general purpose routine here) ?
>
> I'm not the original poster, but in my case...because I do contract work
> for the occasional webmaster who runs IIS and has a
> Microsoft-distributed Perl 5.003 (?) distribution which does not include
> the CGI.pm modules.
>
> Getting CGI.pm installed is not possible because that would require them
> to create a subdirectory (Oooh! Ahhh!), and distribute two files when
> only one is apparently necessary. Also, I have no way of testing the
> CGI.pm installation. (I run UNIX, they run NT). They can't install the
> module from CPAN, and since it's not Activestate they can't use PPM to
> install it.
>
> Can a UNIX CGI.pm (Perl 5.005) be lifted out of a UNIX distribution and
> be put on an NT box (Perl 5.003)? Probably...maybe...Are there
> dependancies that would need to get resolved?
>
> Figuring out (at CGI runtime) where a locally installed CGI.pm isn't
> much fun. (Thanks to the Perl Cookbook). Especially when the webmaster
> just picks up the script referenced in the form, and moves it from
> system...to system...
>
> I roll my own because it's robust from an installation/distribution
> point of view. Yes I steal code from CGI.pm, becuase I don't want to
> completely re-invent the wheel, but I don't want phone calls because the
> script broke when moved from system A to system B.
------------------------------
Date: Mon, 04 Jan 1999 22:47:15 GMT
From: "Caitlin" <caitlin@nospam.backstreet.net>
Subject: Perl 5 for NT: How to do an End Process on a deadlocked Perl process
Message-Id: <Txbk2.4399$Uv.645@news.rdc1.va.home.com>
I have a number of users that are playing with Perl on our
NT IIS3 server. From time to time their script will go into
an infinite loop or become deadlocked waiting on a flock.
The CPU is pinned at 100% and I can't figure out kill these
Perl scripts.
If I try to use End Process from Task Manager I get an
"Access is denied" error message. I'm logged in as the
admin but I fear that since the parent of the Perl process
is a system service (i.e. IIS) I'm out of luck. Is there any
way to "kill" a Perl process without "killing" the author of
the script?
--
Caitlin
------------------------------
Date: 04 Jan 1999 16:16:36 -0700
From: Daniel Grisinger <dgris@moiraine.dimensional.com>
Subject: Re: Perl 5 for NT: How to do an End Process on a deadlocked Perl process
Message-Id: <m3yanid3xn.fsf@moiraine.dimensional.com>
"Caitlin" <caitlin@nospam.backstreet.net> writes:
<snip NT administration problem>
And what, pray tell, does trying to kill NT processes have to
do with perl?
Oh yeah, nothing. Go away.
dgris
--
Daniel Grisinger dgris@moiraine.dimensional.com
perl -Mre=eval -e'$_=shift;;@[=split//;;$,=qq;\n;;;print
m;(.{$-}(?{$-++}));,q;;while$-<=@[;;' 'Just Another Perl Hacker'
------------------------------
Date: Tue, 5 Jan 1999 01:35:57 +0200
From: "fff" <regevs@mishkei.org.il>
Subject: Perl file handling
Message-Id: <76rj93$t56$1@news.netvision.net.il>
Hello,
A rather basic question:
I have an ascii file, and a line number. All I want to do is delete the Nth
line of the file. An alternative question might be, how can I quickly remove
the Nth cell from an array.
Thank you,
Plaza
------------------------------
Date: 04 Jan 1999 19:17:30 -0500
From: Uri Guttman <uri@ibnets.com>
To: "fff" <regevs@mishkei.org.il>
Subject: Re: Perl file handling
Message-Id: <39vhimr2sl.fsf@ibnets.com>
>>>>> "f" == fff <regevs@mishkei.org.il> writes:
f> Hello, A rather basic question: I have an ascii file, and a line
f> number. All I want to do is delete the Nth line of the file. An
f> alternative question might be, how can I quickly remove the Nth
f> cell from an array.
the alternative is answered:
perldoc -f splice
or as they say, seek and ye shall find!
uri
--
Uri Guttman Hacking Perl for Ironbridge Networks
uri@sysarch.com uri@ironbridgenetworks.com
------------------------------
Date: Tue, 05 Jan 1999 00:38:29 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Perl file handling
Message-Id: <9adk2.27$Mw1.1154@nsw.nnrp.telstra.net>
In article <76rj93$t56$1@news.netvision.net.il>,
"fff" <regevs@mishkei.org.il> writes:
> Hello,
>
> A rather basic question:
That is why it is in the perl FAQ, installed with perl, accessible
with perldoc:
# perldoc perlfaq
> I have an ascii file, and a line number. All I want to do is delete
> the Nth line of the file. An alternative question might be, how can
> I quickly remove the Nth cell from an array.
# perldoc -q 'delete.*line'
=head1 Found in /usr/local/lib/perl5/5.00502/pod/perlfaq5.pod
=head2 How do I change one line in a file/delete a line in a
file/insert a line in the middle of a file/append to the beginning of
a file?
[snip]
You may also want to read up on the splice operator
# perldoc -f splice
> Thank you,
No problem.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | Think of the average person. Half of
Commercial Dynamics Pty. Ltd. | the people out there are dumber.
NSW, Australia |
------------------------------
Date: Mon, 04 Jan 1999 17:20:14 +0100
From: "J|rgen Ibelgaufts" <ibelgaufts@gfc-net.de>
Subject: Re: Perl Scripts on NT with Sounds
Message-Id: <3690EA3E.6157DBF0@gfc-net.de>
Hi Joe,
Try the Win32 Modules one of which is Win32::Sound. It is very easy to use:
use Win32::Sound
$result = Win32::Sound::Play("Mysound.wav");
will play the sound.
hope this helps
juergen ibelgaufts
---------------------------------------------------------------------
Joe schrieb:
>
> Hi,
>
> I'm using perl on NT to check for various processes.
>
> When a process fails I want to be able to send sounds out to the users
> indicating what's going wrong.
>
> I have a number of wav files that I need to play but I am unsure how to
> play them via a perl script.
>
> Does anyone know how to do this ?
>
> thanks
>
> Joe...
------------------------------
Date: Mon, 04 Jan 1999 14:59:27 -0800
From: Jennifer Stone <admin@oneseek.com>
Subject: perlcc compiling to bytecode
Message-Id: <369147CE.4389@oneseek.com>
Hi,
The perlcc compiler documentations says it is possible to compile perl
source into "platform-independent byte-code".
Has anyone ever tried this? Once a script is compiled in this way, how
do you run it?
Note, that I am interested in compiling into a plaform-independent
format -- not into c-code or into a platform-dependent executable.
Thanks for any info.
Jennifer Stone
------------------------------
Date: Mon, 04 Jan 1999 21:17:04 GMT
From: Surgeman@concentric.net
Subject: Please Help!!
Message-Id: <76rb4e$igc$1@nnrp1.dejanews.com>
I have gotten myself into a fine mess! I got a new job as a Webmaster (HTML
coder) figuring I wouldn't have to write a CGI, and I now have to write a CGI
so I got a book on Perl and am frantically trying to got it to work for the
Beta is Due (on Jan. 14) and everything I try doesn't work. Here is the code:
open(OP,">>triviaSub.dat") or die "Can't open the Log File";
$in=(STDIN=~s/\+/" "/g);
$IN=($in=~s/\%40/"@"/);
$In=($IN=~s/\%0D%0A/" "/g);
$_IN=($In=~s/\%**/" "/g);
@triv=split/&/g,$_IN,19;
print OP '$triv[0]\n\r';
print OP '$triv[1]\n\r';
print OP '$triv[2]\n\r';
print OP '$triv[3]\n\r';
print OP '$triv[4]\n\r';
print OP '$triv[5]\n\r';
print OP '$triv[6]\n\r';
print OP '$triv[7]\n\r';
print OP '$triv[8]\n\r';
print OP '$triv[9]\n\r';
print OP '$triv[10]\n\r';
print OP '$triv[11]\n\r';
print OP '$triv[12]\n\r';
print OP '$triv[13]\n\r';
print OP '$triv[14]\n\r';
print OP '$triv[15]\n\r';
print OP '$triv[16]\n\r';
print OP '$triv[17]\n\r';
print OP '$triv[18]\n\r';
close OP;
Any helpful input would be greatly appriciated. Thank you for your time and
have a nice day.
Christopher M. Saint Ours
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Tue, 05 Jan 1999 00:25:24 +0100
From: Staffan Liljas <staffan@ngb.se>
Subject: Re: Please Help!!
Message-Id: <36914DE4.17F6158@ngb.se>
Hi!
> I have gotten myself into a fine mess!
I'd say. Would you try saying what the script is supposed to do, and
how? It doesn't really make any sense (to me)
------------------------------
Date: Tue, 05 Jan 1999 00:01:06 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Please Help!!
Message-Id: <6Dck2.18$Mw1.1018@nsw.nnrp.telstra.net>
In article <76rb4e$igc$1@nnrp1.dejanews.com>,
Surgeman@concentric.net writes:
> I have gotten myself into a fine mess! I got a new job as a
> Webmaster (HTML coder) figuring I wouldn't have to write a CGI, and
> I now have to write a CGI so I got a book on Perl and am frantically
If you need to write CGI stuff, the first thing you should do is use
the CGI module. It does all the nasty work for you, helps you with
debugging, and has many other goodies. it should be installed with any
recent version of perl.
> trying to got it to work for the Beta is Due (on Jan. 14) and
> everything I try doesn't work. Here is the code:
Instead of saying 'It doesn't work', you should tell us what you
expect it to do, which part of your expectations is not fulfilled, and
what the error messages are, if any, or the unexpected behaviour.
# perldoc CGI
> open(OP,">>triviaSub.dat") or die "Can't open the Log File";
You check the return of an open, good.
It's probably a good idea to include the $! variable in that error
string, so you know why it went wrong. (perldoc perlvar will tell you
what it does)
> $in=(STDIN=~s/\+/" "/g);
What is this suposed to do? STDIN is a file handle. Did you want to
read the first line from STDIN? You need the angle bracket operators
there. Are you maybe trying to process the input from a POST?
Advice: Don't do it. If you have to do it yourself, check a few things
first, as is standard CGI programming practice. But it's much much
much much x 1000 better to just use the CGI.pm module, and let that
worry about all the ickies of CGI.
> $IN=($in=~s/\%40/"@"/);
> $In=($IN=~s/\%0D%0A/" "/g);
> $_IN=($In=~s/\%**/" "/g);
I am not sure =what this is supposed to do, but are you trying to url
decode a string? Again: CGI.pm does that for you, and does it
correctly.
> @triv=split/&/g,$_IN,19;
> print OP '$triv[0]\n\r';
Many prints can be better done with a here-doc syntax (perldoc
perldata). Many prints of all the elements in an array are better done
with some for or foreach loop construct.
foreach my $el (@triv)
{
print OP "$el\n";
}
You will also benefit from learning the difference between double and
single quotes in perl.
> Any helpful input would be greatly appriciated. Thank you for your time and
> have a nice day.
Before you can program a CGI application, you really should be at
least reasonably comfortable with the language you are going to use,
in this case Perl. Buy a good book on Perl (Programming Perl,
O'Reilly, some others suggested at http://www.perl.com)
Honestly, if you're not a programmer, if you're not familiar with any
language, especially with Perl, then I don't believe at all that the
Jan 14 deadline will be realistic for any CGI project. Using the CGI
module will help tremendously, but not knowing the language at all
will be a big blocker.
The best advice I can give you is to hire someone to do the
programming.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | Little girls, like butterflies, need no
Commercial Dynamics Pty. Ltd. | excuse - Lazarus Long
NSW, Australia |
------------------------------
Date: Mon, 04 Jan 1999 19:37:01 -0500
From: Eugene Sotirescu <eugene@verticalnet.com>
To: Surgeman@concentric.net
Subject: Re: Please Help!!
Message-Id: <36915EAD.6C9D4B43@verticalnet.com>
Ouch!
You need (in this order):
1. A reprieve from your deadline.
2. "Learning Perl" by Randal Schwartz; it should teach you the basics of Perl,
even if you haven't done any kind of programming before (HTML doesn't count as
programming in this context).
3. The CGI.pm module (installed and learned).
http://stein.cshl.org/WWW/software/CGI/cgi_docs.html
See also the CGI resources at:
http://computerdog.com/CGI_MetaFAQ.html
4. Good luck (tho if you've gone thru 2. and 3. this item might not be needed.
In any case, if this is over your head say so and get someone else to do it,
don't let it spoil Perl for you. You can then learn at your leisure and do the
next CGI project yourself. Post here with the code that gives you trouble, what
you expect it to do and what you get instead.
Surgeman@concentric.net wrote:
> I have gotten myself into a fine mess! I got a new job as a Webmaster (HTML
> coder) figuring I wouldn't have to write a CGI, and I now have to write a CGI
> so I got a book on Perl and am frantically trying to got it to work for the
> Beta is Due (on Jan. 14) and everything I try doesn't work. Here is the code:
>
> open(OP,">>triviaSub.dat") or die "Can't open the Log File";
> $in=(STDIN=~s/\+/" "/g);
> $IN=($in=~s/\%40/"@"/);
> $In=($IN=~s/\%0D%0A/" "/g);
> $_IN=($In=~s/\%**/" "/g);
> @triv=split/&/g,$_IN,19;
> print OP '$triv[0]\n\r';
> print OP '$triv[1]\n\r';
> print OP '$triv[2]\n\r';
> print OP '$triv[3]\n\r';
> print OP '$triv[4]\n\r';
> print OP '$triv[5]\n\r';
> print OP '$triv[6]\n\r';
> print OP '$triv[7]\n\r';
> print OP '$triv[8]\n\r';
> print OP '$triv[9]\n\r';
> print OP '$triv[10]\n\r';
> print OP '$triv[11]\n\r';
> print OP '$triv[12]\n\r';
> print OP '$triv[13]\n\r';
> print OP '$triv[14]\n\r';
> print OP '$triv[15]\n\r';
> print OP '$triv[16]\n\r';
> print OP '$triv[17]\n\r';
> print OP '$triv[18]\n\r';
> close OP;
> Any helpful input would be greatly appriciated. Thank you for your time and
> have a nice day.
>
> Christopher M. Saint Ours
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Mon, 04 Jan 1999 17:31:07 +0100
From: "J|rgen Ibelgaufts" <ibelgaufts@gfc-net.de>
Subject: Problems with Win32::API
Message-Id: <3690ECCB.6D6B72A2@gfc-net.de>
Hi there,
i am just trying some things with Win32::API to make the common windows dialogs
available for perl. Some things work (for example the Beep function in the
kernel32.dll which makes a sound with a given frequency and milliseconds.
Now i try the GetOpenFileName function It seems easy to use because it has only
one parameter, but this is a pointer that points to a rather complicated structure
of 20 dwords, integers and other pointers. I get stuck.
Does anyone have any experience with this kind of stuff? The Win32::API
documentation ends long before this point
Thanks in advance
Juergen Ibelgaufts
------------------------------
Date: Mon, 04 Jan 1999 19:07:48 GMT
From: elvis@theking.org (Bob Dubery)
Subject: Re: Programming Rules in Perl
Message-Id: <36911047.8903681@news.icon.co.za>
On Mon, 04 Jan 1999 13:44:39 GMT, hai_long@bigfoot.com wrote:
>I'd like to have some recommendations and rules to start Perl programming in a
>correct way. I've seen some tutorials in Perl.
I'm new to Perl. It seems to me that the area that provides the most
scope for inadvertently inefficient code (not to mention unexpected
results) is in the Regex evaluation engine.
The "camel book" (Programming Perl by Wall, Christiansen and Schwartz)
explains the rules by which the regex engine operates.
If you're learning Perl for the purposes of writing CGI programs then
you should check out www.irt.org.
---
the e-mail address in the headers is bogus
unknot megapode@KNOTicon.co.za to mail me
------------------------------
Date: 4 Jan 1999 20:07:36 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Programming Rules in Perl
Message-Id: <76r728$1m3$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, hai_long@bigfoot.com writes:
:I'd like to have some recommendations and rules to start Perl programming in a
:correct way. I've seen some tutorials in Perl.
Correct is a strong word. But you might look at
http://language.perl.com/style/
and
http://www.perl.com/CPAN-local/doc/manual/html/pod/perlstyle.html
--tom
--
No, I'm not going to explain it. If you can't figure it out, you didn't
want to know anyway... :-)
--Larry Wall in <1991Aug7.180856.2854@netlabs.com>
------------------------------
Date: Tue, 5 Jan 1999 00:28:20 GMT
From: Eric Bohlman <ebohlman@netcom.com>
Subject: Re: Programming Rules in Perl
Message-Id: <ebohlmanF529B9.GEL@netcom.com>
hai_long@bigfoot.com wrote:
: I'd like to have some recommendations and rules to start Perl programming in a
: correct way. I've seen some tutorials in Perl.
With a few exceptions, all of these are "rules" in the sense that you
*can* break them, but you *shouldn't* break them until you've got a
thorough understanding of the language.
1) Every non-broken distribution of Perl comes with a wealth (literally)
of high-quality documentation. It's far more comprehensive and of much
better quality than the documentation that comes with commercial
compilers costing hundreds or even thousands of dollars, and it's
*free*. Get on intimate terms with it. Learn to use the perldoc program
to look up functions and FAQs. Build a mental overview of how it's
organized so that when you have a problem, you know where to look. Every
so often, "water your camel" by picking a piece of documentation at
random and reading it.
2) Familiarize yourself with CPAN, the Comprehensive Perl Archive Network
(URL:http://www.perl.com/CPAN/). One of the great things about Perl is
the number of reusable modules of Perl code that people have written.
All those modules are available to you for free. If you have a
non-trivial requirement, check to see if anybody's written a module that
would help you; that way you avoid reinventing the wheel and you get to
use code that's already been debugged and tested.
3) Always use the -w switch on your programs so that perl can alert you
to places where what you said might not be what you meant.
4) Although by default Perl doesn't require you to pre-declare the
variables you use, you shouldn't rely on this, and in fact you should
declare all your variables (usually with 'my', less often with 'use vars')
and use the 'strict' pragma (i.e. put 'use strict;' (without the quotes of
course) on the second line of your programs) so that perl will complain
about undeclared variables and "barewords" (pieces of literal text
appearing outside quote contexts). It's all too easy to use two different
spelling variants of what's supposed to be the same variable name; 'use
strict' will help you catch this.
5) Whenever you call a function that does anything related to the file
system (opening a file, running an external program, renaming or deleting
files, etc.) *always* test to make sure the operation succeeded, and do
*not* allow your program to plow ahead if the operation fails. When
printing diagnostic messages for file-operation failures, always use the
$! special variable to tell you *why* the operation failed.
6) If you're writing CGI programs, use the CGI.pm module that comes with
every distribution of Perl. Do *not* write your own code to decode CGI
parameters, and do *not* cut-and-paste in someone else's code to do it.
There are lots of buggy parameter-decoding routines floating around.
7) Use single quotes for strings that don't contain any variables to be
interpolated. Double quotes should be a mental reminder that you *are*
interpolating variables.
8) Pay special attention to the proper syntax for addressing array
elements. "@a[0]='first'" is almost always wrong; it should be
"$a[0]='first'".
9) Read the documentation on regular expressions (in perlre) and matching
operators (in perlop) several times; few people can pick it all up in one
reading. Pay special attention to the different ways in which the
matching operators behave depending on whether they're used in scalar or
list context. Learn when to use tr/// in preference to s///.
10) Read the documentation on the printf and sprintf functions, and learn
how to print fractional numbers to the proper number of decimal places.
Read the FAQ that explains why the result of division may be 3.99999999
when you expected 4.0.
11) Learn all the various ways of quoting literal strings. Your literal
strings should never suffer from "Leaning Toothpick Syndrome."
------------------------------
Date: Mon, 4 Jan 1999 09:43:43 -0600
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: READDIR doesn't work
Message-Id: <fjnq67.q2t.ln@magna.metronet.com>
nemanij@hotmail.com wrote:
: Hello,
: Can anyone tellme why this doesn't work
Because of operator precedence, as documented at the very top
of the 'perlop.pod' file.
: opendir(THISDIR, ".") || die " Can't open $dir";
: local(@filenames) = readdir(THISDIR) || die " can't read $dir";
What you have written is the same as:
local(@filenames) = (readdir(THISDIR) || die " can't read $dir");
^ ^
Which is not what you want.
I also think you want my() instead of local() there.
I also also think that you should include the $! special
variable in your diagnostic output.
(my(@filenames) = readdir(THISDIR)) || die " can't read $dir $!";
or
my(@filenames) = readdir(THISDIR) or die " can't read $dir $!";
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: 4 Jan 1999 19:07:07 GMT
From: burt@ici.net (Burt Lewis)
Subject: Re: Reading comma delimited files
Message-Id: <76r3gr$2jk$1@bashir.ici.net>
I save my Excel files as "space delimted" then using a good text editor like
Textpad or Ultraedit, I remove all the spaces. This leaven you with a nice
clean text file. Forget the csv format.
Let me know if this helps.
Burt Lewis
In article <368f3036.2927802145@news>, Simon.Fairall@hpa.com.au says...
>
>I was wondering whether anyone had written a script to parse comma
>delimited files (csv format) as from Microsoft Excel (yuk!).
>
>The problem of using :-
>
>while ($Line = <INFILE>) {
> @FieldList = split (/,/, $line);
>}
>
>to seperate the fields is that a text field (delimited by "") could
>legally contain a comma.
>
>I would appreciate some insight from all you Perl guru's and hackers
>on how to solve this problem.
------------------------------
Date: Mon, 04 Jan 1999 20:17:15 GMT
From: Peter Grimes <grimes@waste.org>
Subject: Re: Reading comma delimited files
Message-Id: <Pine.LNX.3.96.990104141605.23027A-100000@waste.org>
In article <368f3036.2927802145@news>, Simon.Fairall@hpa.com.au says...
>
>I was wondering whether anyone had written a script to parse comma
>delimited files (csv format) as from Microsoft Excel (yuk!).
Check out the following modules:
Text::CSV
Text::CSV_XS (same as above using XS)
Text::ParseWords
It's much easier than writing it yourself.
-Dave
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 4547
**************************************
