[31154] in Perl-Users-Digest
Perl-Users Digest, Issue: 2399 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 7 16:09:47 2009
Date: Thu, 7 May 2009 13:09:12 -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 Thu, 7 May 2009 Volume: 11 Number: 2399
Today's topics:
Re: Help with Net::ftp not downloading <nat.k@gm.ml>
Re: Help with Net::ftp not downloading <nat.k@gm.ml>
IO::Socket::INET on OSX or TCP stack problem <stuart@otenet.gr>
Re: IO::Socket::INET on OSX or TCP stack problem derykus@gmail.com
opening a client application from a server? <cartercc@gmail.com>
Re: opening a client application from a server? <tadmc@seesig.invalid>
Re: Perl command call check <n@solenttechnology.co.uk>
Re: Perl command call check <1usa@llenroc.ude.invalid>
Re: Perl is too slow - A statement <hjp-usenet2@hjp.at>
Re: pod2ipf in Perl 5.10? <nospam-abwillis1-nopspam@nospam-gmail.com>
Re: printing html with perl <tadmc@seesig.invalid>
Re: printing html with perl <1usa@llenroc.ude.invalid>
Re: printing html with perl <kkeller-usenet@wombat.san-francisco.ca.us>
writing get_script() <frank@example.invalid>
Re: writing get_script() <devnull4711@web.de>
Re: writing get_script() <frank@example.invalid>
Re: writing get_script() <jurgenex@hotmail.com>
Re: writing get_script() <frank@example.invalid>
Re: writing get_script() <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 04 May 2009 19:46:30 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Help with Net::ftp not downloading
Message-Id: <bMNLl.8730$ho7.6376@newsfe10.iad>
Ed Jay wrote:
> Nathan Keel wrote:
>
>>Ed Jay wrote:
>>
>>> I'm running a script on the server using my browser.
>>
>>Okay, so did you verify that the web server runs as your own user so
>>it
>>has write permissions? Did you verify that the web service isn't
>>somehow interfering? Did you try running it from the command line to
>>help rule out some things?
>
> I can't run it from the command line.
>
> If the web server was the cause, I wouldn't expect any other ftp
> client to succeed. That's not the case.
>
> Thanks for the advice.
>
I don't want to waste your time by asking irrelevant questions to your
issue, but why can't you run it on the command line? Is this a remote
server that you don't have terminal/cli access to? As for the cause, I
was just saying it's always good to rule out as many things as
possible. I.e., see if you can connect out from that system over FTP
logging in manually, connecting to the FTP site, and get a file that
way. If so, then go to CLI and with verbose output and error checking,
see if it runs on the command line. If it does, then automate it or go
the route of the CGI script.
Of course, you can run it and figure it out without going that route,
but those methods allow for a better test bed and can save time, if you
have that as an option. The web server comment was also to suggest
that the CGI scripts might be running as a different user and maybe the
data is downloading but unable to write due to the permissions. For
that matter, it could be a quota issue on the account or similar
things. You can maybe try running the script from your local system
and see if it works, just anything to rule out other potentials is all
I mean. Good luck.
------------------------------
Date: Mon, 04 May 2009 19:46:30 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Help with Net::ftp not downloading
Message-Id: <jNNLl.8731$ho7.1243@newsfe10.iad>
Ed Jay wrote:
> Nathan Keel wrote:
>
>>Ed Jay wrote:
>>
>>> I'm running a script on the server using my browser.
>>
>>Okay, so did you verify that the web server runs as your own user so
>>it
>>has write permissions? Did you verify that the web service isn't
>>somehow interfering? Did you try running it from the command line to
>>help rule out some things?
>
> I can't run it from the command line.
>
> If the web server was the cause, I wouldn't expect any other ftp
> client to succeed. That's not the case.
>
> Thanks for the advice.
>
I don't want to waste your time by asking irrelevant questions to your
issue, but why can't you run it on the command line? Is this a remote
server that you don't have terminal/cli access to? As for the cause, I
was just saying it's always good to rule out as many things as
possible. I.e., see if you can connect out from that system over FTP
logging in manually, connecting to the FTP site, and get a file that
way. If so, then go to CLI and with verbose output and error checking,
see if it runs on the command line. If it does, then automate it or go
the route of the CGI script.
Of course, you can run it and figure it out without going that route,
but those methods allow for a better test bed and can save time, if you
have that as an option. The web server comment was also to suggest
that the CGI scripts might be running as a different user and maybe the
data is downloading but unable to write due to the permissions. For
that matter, it could be a quota issue on the account or similar
things. You can maybe try running the script from your local system
and see if it works, just anything to rule out other potentials is all
I mean. Good luck.
------------------------------
Date: Thu, 07 May 2009 22:26:21 +0300
From: Stuart Gall <stuart@otenet.gr>
Subject: IO::Socket::INET on OSX or TCP stack problem
Message-Id: <gtvck9$gf4$1@mouse.otenet.gr>
Hello,
I have written a script using IO::Socket::INET to read and write data to
modbus devices. Using blocking IO ->read and ->write.
This is running on OSX V 10.4.11
I have the latest IO::Socket Library from CPAN.
Using perl 5.8.6 from OSX and I built perl 5.10 which has the same issue
The script will work for a few loops, maybe doing 100 or so modbus
read/writes
Then the sockets are closed for no apparent reason.
I copied the same script to another OSX machine running 10.4.11 and I
have the exact same problem.
I copied the script to a machine running Mandrivia 2009 and it works
just fine!
I did a tcpdump, what seams to be happening is that when an error occurs
in a TCP packet, the OSX end gets stuck in a loop requesting and re
requesting the packet.
Until eventually the other end sends RST and force-ably closes the socket.
Any Ideas what might be going on ?
TCPDUMP (192.168.251.3 is the OSX machine)
10:17:19.508241 IP 192.168.251.3.52312 > 192.168.251.102.502: P
160:172(12) ack 90 win 65535 <nop,nop,timestamp 1360281049 65303>
10:17:19.514522 IP 192.168.251.102.502 > 192.168.251.3.52312: P
90:101(11) ack 172 win 5669 <timestamp 65461 1360281049,nop,nop>
10:17:19.514544 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281049 65461>
That was a request and reply acknowledged - Normal
10:17:19.747871 IP 192.168.251.3.52312 > 192.168.251.102.502: P
172:187(15) ack 101 win 65535 <nop,nop,timestamp 1360281049 65461>
Request
10:17:19.752164 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 163 1360281049,nop,nop>
Reply
10:17:19.752183 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281050 65461>
Rejected
10:17:20.501290 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 912 1360281050,nop,nop>
Resent
10:17:20.501355 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281051 65461>
Rejected
10:17:20.750835 IP 192.168.251.3.52312 > 192.168.251.102.502: P
172:187(15) ack 101 win 65535 <nop,nop,timestamp 1360281051 65461>
Resend request (even though it was acknowledged) Is that legal ??
10:17:20.762936 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 1174 1360281051,nop,nop>
Accept
10:17:21.929985 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 2341 1360281051,nop,nop>
Reply Again
10:17:21.930046 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281054 65461>
Rejected
10:17:21.931308 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 2342 1360281054,nop,nop>
Resent
10:17:21.931324 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281054 65461>
Rejected
10:17:21.932624 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 2343 1360281054,nop,nop>
?
And so on
10:17:22.751058 IP 192.168.251.3.52312 > 192.168.251.102.502: P
172:187(15) ack 101 win 65535 <nop,nop,timestamp 1360281055 65461>
10:17:22.759845 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 3171 1360281055,nop,nop>
10:17:24.778286 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 5189 1360281055,nop,nop>
10:17:24.778318 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281060 65461>
10:17:24.779660 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 5190 1360281060,nop,nop>
10:17:26.751479 IP 192.168.251.3.52312 > 192.168.251.102.502: P
172:187(15) ack 101 win 65535 <nop,nop,timestamp 1360281063 65461>
10:17:26.758087 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 7169 1360281063,nop,nop>
10:17:30.470519 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 10881 1360281063,nop,nop>
10:17:30.470583 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281071 65461>
10:17:30.471828 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 10882 1360281071,nop,nop>
10:17:34.752192 IP 192.168.251.3.52312 > 192.168.251.102.502: P
172:187(15) ack 101 win 65535 <nop,nop,timestamp 1360281079 65461>
10:17:34.754071 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 15164 1360281079,nop,nop>
10:17:37.576828 IP 192.168.251.102.502 > 192.168.251.3.52312: P
101:113(12) ack 187 win 5654 <timestamp 17987 1360281079,nop,nop>
10:17:37.576875 IP 192.168.251.3.52312 > 192.168.251.102.502: . ack 101
win 65535 <nop,nop,timestamp 1360281085 65461>
10:17:37.578139 IP 192.168.251.102.502 > 192.168.251.3.52312: . ack 187
win 5654 <timestamp 17988 1360281085,nop,nop>
10:17:50.754009 IP 192.168.251.3.52312 > 192.168.251.102.502: P
172:187(15) ack 101 win 65535 <nop,nop,timestamp 1360281111 65461>
10:17:50.761068 IP 192.168.251.102.502 > 192.168.251.3.52312: R
249188453:249188453(0) win 0
Now I think 192.168.251.102 gets fed up and boots us off
TIA
Stuart.
------------------------------
Date: Thu, 7 May 2009 13:03:16 -0700 (PDT)
From: derykus@gmail.com
Subject: Re: IO::Socket::INET on OSX or TCP stack problem
Message-Id: <81f2a8a8-f521-4c2f-8b11-aa9ed1fd872e@n7g2000prc.googlegroups.com>
On May 7, 12:26=A0pm, Stuart Gall <stu...@otenet.gr> wrote:
> Hello,
> I have written a script using IO::Socket::INET to read and write data to
> modbus devices. Using blocking IO ->read and ->write.
> This is running on OSX V 10.4.11
> I have the latest IO::Socket Library from CPAN.
> ....
No ideas about the problem but I'd recommend showing
some of your code. Seeing actual code often jogs
memories in ways other problem descriptions can't.
What options did you pass to the IO::Socket::INET constructor,
Reuseaddr, Timeout, Blocking, etc.?
--
Charles DeRykus
------------------------------
Date: Thu, 7 May 2009 12:41:49 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: opening a client application from a server?
Message-Id: <c64106fd-a0b6-4361-a72a-88f2f97a2ec2@m24g2000vbp.googlegroups.com>
This relates to the post I made last week about working with
WordProcessingML. That part turned out to be easy -- as easy as
writing a CGI script and dynamically updating the HTML from a
database. WordProcessingML is no different from XHTML and does pretty
good at creating Word documents.
Here's the question: The client has a requirement that the users
create a Word document on a web enabled app and open it in the client
browser. I can create the word document and open it on the server
(using this command -- exec("c:/Program Files/Microsoft Office/
OFFICE12/winword.exe", "c:/TEST1.DOC")) but I can't get Word to open
the file on the client. I can write the .doc file to a directory and
give the client to the directory over the internet, but that doesn't
meet the requirement.
I've tried creating hyperlink like <a href="test.doc">Here is your
Word document</a> but that doesn't work either.
I'm about to tell my client that I can't meet this requirement ...
I've been trying since Monday and have about given up. Any ideas?
Thanks, CC.
------------------------------
Date: Thu, 7 May 2009 15:00:02 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: opening a client application from a server?
Message-Id: <slrnh06fe2.peh.tadmc@tadmc30.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> Here's the question: The client has a requirement that the users
> create a Word document on a web enabled app and open it in the client
> browser. I can create the word document and open it on the server
> (using this command -- exec("c:/Program Files/Microsoft Office/
> OFFICE12/winword.exe", "c:/TEST1.DOC")) but I can't get Word to open
> the file on the client.
If I'm understanding you correctly, then you do not have a Perl problem.
If you send the appropriate (application/word?) Content-Type, then a
client on Windows, with Word installed, should be able to open it
no problem.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 7 May 2009 01:01:05 -0700 (PDT)
From: neilsolent <n@solenttechnology.co.uk>
Subject: Re: Perl command call check
Message-Id: <f89fa97f-b215-4777-a834-000012486ca1@n4g2000vba.googlegroups.com>
> The documentation for the system function explains:
>
Read the manual eh ? Good idea :-)
Thanks for the post - think that has cleared this thread up
I already discovered the common -1 code for $?, but it is useful to
see the official explanation.
------------------------------
Date: Thu, 07 May 2009 13:09:45 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl command call check
Message-Id: <Xns9C045D334DCE7asu1cornelledu@127.0.0.1>
neilsolent <n@solenttechnology.co.uk> wrote in news:f89fa97f-b215-4777-
a834-000012486ca1@n4g2000vba.googlegroups.com:
>
>> The documentation for the system function explains:
>>
>
> Read the manual eh ? Good idea :-)
Always ;-)
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Thu, 7 May 2009 19:26:26 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl is too slow - A statement
Message-Id: <slrnh066e8.blf.hjp-usenet2@hrunkner.hjp.at>
On 2009-05-05 00:22, David Formosa (aka ? the Platypus) <dformosa@usyd.edu.au> wrote:
> On Mon, 04 May 2009 09:45:55 -0700, Nathan Keel <nat.k@gm.ml> wrote:
>> David Formosa (aka ? the Platypus) wrote:
>>
>>> On Sun, 03 May 2009 22:37:30 -0700, Nathan Keel <nat.k@gm.ml> wrote:
>>>> David Formosa (aka ? the Platypus) wrote:
>>>>
>>>>> On Wed, 29 Apr 2009 20:33:23 -0700, Nathan Keel <nat.k@gm.ml> wrote:
>>>>> [...]
>>>>>
>>>>>> What happens when you find that the language isn't fast enough?
>>>>>
>>>>> Lanauges are not fast or slow enough. Applications arn't fast
>>>>> enought.
>>>>
>>>> I don't know what "Lanauges" are, so I'll take your word for it.
>>>
>>> Real classy a spelling flame. Like I haven't seen one of thouse
>>> before.
>>>
>>> http://quollified.com/~platypus/index.html
>>
>> I resorted to picking on the typos because the response you made didn't
>> make sense, even when the spelling was corrected. I didn't take the
>> reply seriously, it looked like you were just posting nonsense for the
>> sake of it, so I poked fun. If you were genuine, then please elaborate
>> and accept my apologies for my assumption.
>
> Ok your claim was "What happens when you find that the language isn't
> fast enough?". My responce was that this question didn't make sence.
> Because languages are not what is fast or slow, applications are fast
> and slow.
I disagree. While a language per se is neither slow nor fast, all
computer languages (which can actually be used) have at least one
implementation (compiler, interpreter, run time system, etc.). For some
languages (like Perl5) there is only implementation, so the speed of
this implementation is also the speed the language (Yes, somebody could
write an alternate Perl5 implementation which was vastly faster or
slower, but nobody did - if you want to run Perl5 programs you need to
use perl). Even for languages with hundreds or thousands
of different implementations (like C or Fortran) some feature of the
language makes certain optimizations simple or difficult, so it makes
sense to say that for a certain class of problems Fortran is faster than
C: That doesn't mean that all Fortran programs for this class of
problems run faster that all C programs: But if you have a C programmer
and a Fortran programmer of roughly equivalent skill and a C compiler
and a Fortran compiler of roughly comparable sophistication, the chances
are good that the Fortran program will run faster than the C program on
the same hardware.
For an interpreted language like Perl, the class of problems which
simply cannot be solved efficiently in this language is relatively
large. Fortunately, such languages can usually call subroutines written
in other languages. So the answer for the question "What happens when
you find that perl isn't fast enough?" may sometimes be: You identify
the bottleneck and rewrite that part of the code as an XS module.
hp
------------------------------
Date: Thu, 7 May 2009 19:08:00 +0000 (UTC)
From: "Andy" <nospam-abwillis1-nopspam@nospam-gmail.com>
Subject: Re: pod2ipf in Perl 5.10?
Message-Id: <stfVq7QNr4pc-pn2-kmOKCvv7doEJ@comp1>
On Wed, 29 Apr 2009 09:55:19 UTC, "Paul Smedley"
<pauldespam@despamsmedley.id.au> wrote:
> Hi Shmuel,
>
> On Tue, 28 Apr 2009 12:52:26 UTC, Shmuel (Seymour J.) Metz
> <spamtrap@library.lspace.org.invalid> wrote:
>
> > In <POn1Xm9ddZOp-pn2-HGd75dgbvE56@smedley.info>, on 04/26/2009
> > at 10:07 PM, "Paul Smedley" <pauldespam@despamsmedley.id.au> said:
> >
> > >I don't see a 5.10.1
> >
> > Perl 5.10.1 is a projected bug-fix release that is expected imminently. I
> > don't know whether you normally do builds for such.
> Yeah I probably will - I do for things like mysql, apache2, etc
>
>
> > >I don't plan on installing any external packages
> >
> > But is something documented in perlos2 really an external package for an
> > OS/2 release? Do you plan on creating an INF the next time around?
> I've never even looked at perlos2 - and have no idea how to create an
> INF... so I guess that's a know unless someone wants to help create
> it.
>
> I'd like to work out why my perl builds can't be used to build mozilla
> - just need to find a few more extra hours in the week - getting
> harder and harder the way my day job is going right now....
>
Works fine here for building Mozilla. I am using the wpi that was
released (don't recall by whome) but had to update the
klibcpathrewriters as it set /perl and it needed to set /perl5.
Andy
--
------------------------------
Date: Thu, 7 May 2009 07:34:49 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: printing html with perl
Message-Id: <slrnh05lb9.ho1.tadmc@tadmc30.sbcglobal.net>
Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> On 2009-05-07, Tad J McClellan <tadmc@seesig.invalid> wrote:
>>
>> I always use CGI.pm for parsing form arguments.
>>
>> I never use CGI.pm for generating HTML.
>
> There are some cute features of CGI.pm.
> print $cgi->li([1,2,3,4]);
A very nice example of why I never use CGI.pm for generating HTML. :-)
I never use CGI.pm for generating HTML because it obscures (for me
anyway) the program's output.
i.e. It makes debugging harder.
(errr, IE makes debugging harder too, but that's a different thing :-)
>> I often use CGI.pm for other things.
>
> There isn't much else to CGI.pm, is there?
I had cookie(), redirect() and header() in mind when I wrote that.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 07 May 2009 17:05:54 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: printing html with perl
Message-Id: <Xns9C04853C83294asu1cornelledu@127.0.0.1>
Tad J McClellan <tadmc@seesig.invalid> wrote in
news:slrnh05lb9.ho1.tadmc@tadmc30.sbcglobal.net:
> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>> On 2009-05-07, Tad J McClellan <tadmc@seesig.invalid> wrote:
>>>
>>> I always use CGI.pm for parsing form arguments.
>>>
>>> I never use CGI.pm for generating HTML.
...
>
>>> I often use CGI.pm for other things.
>>
>> There isn't much else to CGI.pm, is there?
>
> I had cookie(), redirect() and header() in mind when I wrote that.
I really like http://search.cpan.org/~andya/CGI-Simple-1.109/
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Thu, 7 May 2009 11:43:53 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: printing html with perl
Message-Id: <aombd6xg95.ln2@goaway.wombat.san-francisco.ca.us>
On 2009-05-07, Tad J McClellan <tadmc@seesig.invalid> wrote:
> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>>
>> There are some cute features of CGI.pm.
>
>> print $cgi->li([1,2,3,4]);
>
> A very nice example of why I never use CGI.pm for generating HTML. :-)
>
> I never use CGI.pm for generating HTML because it obscures (for me
> anyway) the program's output.
Heh. :)
I think it's five of one, seven of the other: I like that it makes the
code much cleaner, even though it's not immediately obvious what the
output is. But a large project shouldn't be doing this kind of thing
anyway; I (try to) use something like the above only in one-off
programs, or programs not intended for others to use.
>> There isn't much else to CGI.pm, is there?
>
> I had cookie(), redirect() and header() in mind when I wrote that.
Good point. I'd lumped them into HTML, but they're printing HTTP
headers, not HTML.
You can use the arrayref trick with cookies too:
print $cgi->header(
-cookie=>[$cookie1,$cookie2,$cookie3]);
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Thu, 7 May 2009 11:20:01 -0700
From: Franken Sense <frank@example.invalid>
Subject: writing get_script()
Message-Id: <19qabkudlobab$.1vckpugellkld.dlg@40tude.net>
How do I write a get_script() for data that look like these:
44:004:037 Having land, sold it, and brought the money, and laid it at
the apostles' feet.
44:005:001 But a certain man named Ananias, with Sapphira his wife, sold
a possession,
44:005:002 And kept back part of the price, his wife also being privy to
it, and brought a certain part, and laid it at the apostles'
feet.
Here's what I'm looking to do:
1) Have the numbers populate $book, $chp, $verse.
2) Remove the newline when not at the end of a verse.
3) Have get_script() be an external function that is called by main in C.
My first attempts are usually pretty feeble and/or methodologically flawed.
Somehow I'd like to use perl's pattern matching for input and then use C to
insert the data into a binary tree.
Thanks for your comment.
--
Frank
...................... o _______________ _,
` Good Morning! , /\_ _| | .-'_|
`................, _\__`[_______________| _| (_|
] [ \, ][ ][ (_|
------------------------------
Date: Thu, 07 May 2009 19:34:10 +0200
From: Frank Seitz <devnull4711@web.de>
Subject: Re: writing get_script()
Message-Id: <76gkc8F1d4abpU1@mid.individual.net>
Franken Sense wrote:
>
> Somehow I'd like to use perl's pattern matching for input and then use C to
> insert the data into a binary tree.
>
> Thanks for your comment.
What a strange approach. Why do you think that you need Perl to
process this simple-structured input data?
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
------------------------------
Date: Thu, 7 May 2009 11:45:15 -0700
From: Franken Sense <frank@example.invalid>
Subject: Re: writing get_script()
Message-Id: <15fp5tnr408do$.1qnxofefkhydz$.dlg@40tude.net>
In Dread Ink, the Grave Hand of Franken Sense Did Inscribe:
> My first attempts are usually pretty feeble and/or methodologically flawed.
> Somehow I'd like to use perl's pattern matching for input and then use C to
> insert the data into a binary tree.
For better or worse, I start where I left off before.
use strict;
use warnings;
# open input file
my $filename = 'text43.txt';
open(my $fh, '<', $filename) or
die "cannot open $filename for reading: $!";
# open output file
my $filename2 = 'outfile10.txt';
open(my $gh, '>', $filename2) or
die "cannot open $filename2 for writing: $!";
# process all lines in input file
while( my $line = <$fh> ) {
chomp($line);
my @s = split /\s+/, $line;
# modify fields
$s[1] =~ s/h//;
$s[2] =~ s/m//;
$s[3] =~ s/s//;
$s[5] =~ s/'//;
# print modified fields
for my $i (0..$#s) {
print "s[$i] = $s[$i]\n";
}
# write modified fields to output file
my $outline = join(' ', @s);
print $gh "$outline\n";
}
# close input and output files
close($gh) or die("Error closing $filename2: $!");
close($fh) or die("Error closing $filename: $!");
__END__
sample output:
44:028:021 And they aid unto him, We neither received letters out of
Judaea concerning thee, neither any of the brethren that came
sewed or pake any harm of thee.
44:028:022 But we deire to hear of thee what thou thinkest: for as
concerning this ect, we know that every where it is spoken
against.
The good news here is that I'm opening and closing files correctly. The
bad news is that these scripts tend to be a few lines long, so I can't
process it line by line and split it up into fields that way.
How do I make a single input record to be what lies between the ##:###:###
?
--
Frank
I do personal attacks only on people who specialize in personal attacks..
~~ Al Franken, Playboy interview
------------------------------
Date: Thu, 07 May 2009 10:45:39 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: writing get_script()
Message-Id: <t276051t7u36tec6cn7432fbq59c3k5tat@4ax.com>
Franken Sense <frank@example.invalid> wrote:
>How do I write a get_script() for data that look like these:
>
>44:004:037 Having land, sold it, and brought the money, and laid it at
> the apostles' feet.
>
>44:005:001 But a certain man named Ananias, with Sapphira his wife, sold
> a possession,
>
>44:005:002 And kept back part of the price, his wife also being privy to
> it, and brought a certain part, and laid it at the apostles'
> feet.
>
>Here's what I'm looking to do:
>
>1) Have the numbers populate $book, $chp, $verse.
split() the line at the first space character, then split() the first
part again into ($book, $chp, $verse).
>2) Remove the newline when not at the end of a verse.
May I suggest a different structure for your data?
Change the input_record_separator $/ into two consecutive newlines. Then
the whole verse will be read as a single unit, allowing you to
a) extract the numbers without worrying about if you are looking at a
first line or follow-up line within the same verse
b) blindly remove all newlines from within the verse and add whatever
number you like at its end
>3) Have get_script() be an external function that is called by main in C.
Can't comment on that.
>My first attempts are usually pretty feeble and/or methodologically flawed.
>Somehow I'd like to use perl's pattern matching for input and then use C to
>insert the data into a binary tree.
Why? You can build binary trees in Perl, no problem.
jue
------------------------------
Date: Thu, 7 May 2009 11:51:36 -0700
From: Franken Sense <frank@example.invalid>
Subject: Re: writing get_script()
Message-Id: <1qzry6j9kl4nk.1m5iai7gyqsc7$.dlg@40tude.net>
In Dread Ink, the Grave Hand of Frank Seitz Did Inscribe:
> Franken Sense wrote:
>>
>> Somehow I'd like to use perl's pattern matching for input and then use C to
>> insert the data into a binary tree.
>>
>> Thanks for your comment.
>
> What a strange approach. Why do you think that you need Perl to
> process this simple-structured input data?
>
> Frank
I frequently find myself wishing I had perl for input. This seems simple
enough for me to solve.
I see you live in Wedel. I used to live in Pinneberg. I miss the
bakeries.
--
Frank
I once asked the most fabulous couple I know, Madonna and Guy Ritchie, how
they kept things fresh despite having been married for almost seven months.
'It's a job, Al,' Guy told me. 'We work at it every day.'
~~ Al Franken,
------------------------------
Date: Thu, 7 May 2009 19:07:59 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: writing get_script()
Message-Id: <vkkbd6-nmb1.ln1@osiris.mauzo.dyndns.org>
Quoth frank@example.invalid:
>
> 44:028:021 And they aid unto him, We neither received letters out of
> Judaea concerning thee, neither any of the brethren that came
> sewed or pake any harm of thee.
>
> 44:028:022 But we deire to hear of thee what thou thinkest: for as
> concerning this ect, we know that every where it is spoken
> against.
>
> The good news here is that I'm opening and closing files correctly. The
> bad news is that these scripts tend to be a few lines long, so I can't
> process it line by line and split it up into fields that way.
>
> How do I make a single input record to be what lies between the ##:###:###
> ?
$/ = "";
Ben
------------------------------
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 V11 Issue 2399
***************************************
