[30448] in Perl-Users-Digest
Perl-Users Digest, Issue: 1691 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 5 03:09:44 2008
Date: Sat, 5 Jul 2008 00:09:09 -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 Sat, 5 Jul 2008 Volume: 11 Number: 1691
Today's topics:
Re: Formatting ASCII to be read by Windows NotePad <wgumgfy@gmail.com>
Re: Formatting ASCII to be read by Windows NotePad <sbour@niaid.nih.gov>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Formatting ASCII to be read by Windows NotePad <ben@morrow.me.uk>
Re: Formatting ASCII to be read by Windows NotePad <wgumgfy@gmail.com>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: kill process when file number reached... <whynot@pozharski.name>
new CPAN modules on Sat Jul 5 2008 (Randal Schwartz)
Re: Perl CGI utilities? <waveright@gmail.com>
Re: Perl CGI utilities? <spamtrap@dot-app.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 4 Jul 2008 17:49:56 -0700
From: "Waylen Gumbal" <wgumgfy@gmail.com>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <6d7upmF1bjeqU1@mid.individual.net>
Sherman Pendley wrote:
> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
>> Sherman Pendley wrote:
> > >
> > > First you claim that a particular OS may have problems,
> >
> > I never made any such claim.
>
> Your own words, directly copied and pasted:
>
> "While it is common to use ASCII mode one should still take care, as
> this isn't always guarenteed to work. There used (still are?) issues
> with this when uploading to MacOS based servers, for example."
Yes, as I have run into such issues in the past. I'm still not sure why
you are turning a simple comment into a federal investigation.
> > > then when I asked for details you gave me a bunch of hand-waving
> > > about an FTP server supposedly not informing the client what it
> > > was,
> > > when in fact *no* FTP server does so for ASCII transfers, nor
> > > needs
> > > to.
> >
> > Because it was some time ago. I was just recalling an experience.
> > Why do you care so damn much anyways? Who asked you to be a lawyer?
>
> I care about accuracy in the technical fora in which I participate -
> and I don't recall needing to be asked by you to care about it.
Caring about accuracy is one thing, but you're clearing taking a simple
comment and making it into something it's clearly not. You seem to be
bent on making WWIII out of a paint ball battle, for what reason I
really don't know.
> > > In this whole sorry thread, I've yet to see a single coherent,
> > > logical description of the problem you supposedly had. Nor have I
> > > seen a bit of evidence that you know anything about the FTP
> > > protocol.
> >
> > I don't have to prove any thing. I know how FTP work
>
> Do you? Then why did you - again, your own words - "attribute the
> problem likely was the server wasn't properly telling the client what
> sort of platform it was"?
Christ, it was a guess. Again, why are you making Mt. Everest out of a
half-foot tall ant hill? This is not simple fact hunting on your part,
it is some obsession of yours where it seems you wont stop until I'm
politely kissing your shoes. News flash: no one likes being talked to,
and it's certainly not a way to make someone see your view.
> If you actually knew how FTP works, at the protocol level, you would
> know that no server ever tells the client that. It doesn't need to -
> both client and server transforms the text to and from its native
> format to ASCII with \r\n for transport. Neither one needs to know or
> care about the native format of the other.
I never claimed to know how every inch and cm of the FTP protocol, so
why are you making this assertion? Why are you so obsessed with this?
> > and I know there
> > are many server and client implementations released over the years
> > that could misbehave when it comes to converting EOLs.
>
> I worked in web hosting for many years, and I've answered this and
> similar questions literally hundreds of times. In every single case,
> without exception, the answer was that the user was expecting ASCII
> mode to handle translations that it isn't designed to handle.
I have been there too, and in many other situations on various
platforms. Just because you haven't seen a particular issue doesn't mean
it doesn't exist. At least one other poster here has pointed out problem
with a particular client that incorrectly converted EOLs, and I've seen
many other EOL conversion issues.
> For instance, if one uploads a file with \r in binary mode to a Unix
> server, it's not in the server's native text format. So, when someone
> else downloads that file later on, in ASCII mode, the server doesn't
> translate it - there are no \n's in the file to translate, and an FTP
> server will *only* translate its native format.
This is likely where some problems arise. Other arise from improperly
configured software, at either end. Or a mix thereof.
> The most common cause of problems, in my experience, is users who
> expect ASCII mode to translate all kinds of line endings to the
> client's native format, when in fact that's not what is supposed to
> happen.
This is true, but it's not the only reason.
> > There is no reason to
> > act this way, and in many people's eyes you come off as entirely
> > condescending. Please be civil of fsck off.
>
> I *am* being civil. I'm simply correcting misinformation; if your
> feelings are hurt in the process, that's your problem. If you can't
> stand being corrected, check your facts before posting.
What misinformation? What correction? I stated a comment based on my own
experience, and you want to tell me I didn't see what I did in fact see?
What makes you so qualified to tell me what my own experiences are?
--
wg - and no I'm not going to kiss your ass
------------------------------
Date: Fri, 4 Jul 2008 18:02:31 -0700
From: "Stephan Bour" <sbour@niaid.nih.gov>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <IKzbk.31398$ZE5.7903@nlpi061.nbdc.sbc.com>
Sherman Pendley wrote:
} "Waylen Gumbal" <wgumgfy@gmail.com> writes:
}
} > Sherman Pendley wrote:
} > > UnRiel <bdwhite@gmail.com> writes:
} > >
} > > > I have a nice PERL script I use to generate CISCO configurations
} > >
} > > No need to shout - neither Perl nor Cisco are acronyms.
} >
} > I don't think two all-caps words in a sentence that's otherwise
} > properly cased really constitutes shouting.
}
} It's shouting those words.
Nonesense. Obviously you know what he meant by "PERL" and "CICSO", there
really isn't anything wrong about writing it that way, unless you want to be
an absolute perfectionist.
} > > Transfer the files in text mode. That will translate the line
} > > endings as needed.
} >
} > While it is common to use ASCII mode one should still take care, as
} > this isn't always guarenteed to work. There used (still are?) issues
} > with this when uploading to MacOS based servers, for example.
}
} Such as?
I've seen some pretty crazy where file that originally had \r\n ended up
being \r\n\n, which interestingly, occurred with a version of Serv-U (which
I recall was fixed in the next release),
And while not FTP, I've seen interesting line-terminator situations from web
forms ,for text coming from a TEXTAREA, though this was probably more the
fault of server-side scripting that handled the form input, making poor
assumptions about the incoming data.
Either way, it's always prudent to check to make sure a file has transferred
the way you think it has. If you're uploading to a UNIX-based server, you
can write a simply script to do a hex-dump of a file. If you see 0D0A when
you expect 0D, then something went wrong, and you should never assume, when
dealing with a foreign server you haven't used before, that it will have
transferred properly and that it needn't be checked.
Stephan.
------------------------------
Date: Fri, 04 Jul 2008 22:19:19 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1lk0hgjiw.fsf@dot-app.org>
"Waylen Gumbal" <wgumgfy@gmail.com> writes:
> Sherman Pendley wrote:
>> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
>>> Sherman Pendley wrote:
>> > >
>> > > First you claim that a particular OS may have problems,
>> >
>> > I never made any such claim.
>>
>> Your own words, directly copied and pasted:
>>
>> "While it is common to use ASCII mode one should still take care, as
>> this isn't always guarenteed to work. There used (still are?) issues
>> with this when uploading to MacOS based servers, for example."
>
> Yes, as I have run into such issues in the past. I'm still not sure why
> you are turning a simple comment into a federal investigation.
I asked you a simple question - "Such as?" What's so unreasonable
about that question? Why are you dodging it? If you know of a specific
problem with Mac FTP servers, just say so - I use a Mac every day and
I'd love to know about it.
>> Do you? Then why did you - again, your own words - "attribute the
>> problem likely was the server wasn't properly telling the client what
>> sort of platform it was"?
>
> Christ, it was a guess.
Then why didn't you say so? Why are you trying to pass off a guess as
knowledgable advice?
> half-foot tall ant hill? This is not simple fact hunting on your part,
> it is some obsession of yours where it seems you wont stop until I'm
> politely kissing your shoes. News flash: no one likes being talked to,
> and it's certainly not a way to make someone see your view.
I don't care what you kiss or what you like. I'm correcting nonsense
for the sake of those who might otherwise believe it. Can you cite one
shred of *logical*, *fact-based* evidence that FTP problems are more
common on Mac servers than on others, or can't you?
Or, to put it in Wiki terms - [citation needed].
>> If you actually knew how FTP works, at the protocol level, you would
>> know that no server ever tells the client that. It doesn't need to -
>> both client and server transforms the text to and from its native
>> format to ASCII with \r\n for transport. Neither one needs to know or
>> care about the native format of the other.
>
> I never claimed to know how every inch and cm of the FTP protocol, so
> why are you making this assertion?
Because you claimed to have accurately diagnosed a problem with an
FTP server. Without a protocol-level understanding of FTP, such a
claim is pretty hard to swallow.
> Why are you so obsessed with this?
What's with the armchair psychology? We're having a discussion. It's
not a federal case, WWIII, or an obsession. Why are you trying to
paint me as a lunatic - are you trying to distract from the fact that
you have no evidence whatsoever to support your assertion?
> I have been there too, and in many other situations on various
> platforms. Just because you haven't seen a particular issue doesn't mean
> it doesn't exist. At least one other poster here has pointed out problem
> with a particular client that incorrectly converted EOLs, and I've seen
> many other EOL conversion issues.
Nice straw man. I'm not denying that there can be "issues"; what I'm
denying is your assertion that they're more common when the server is
running on a Mac.
>> I *am* being civil. I'm simply correcting misinformation; if your
>> feelings are hurt in the process, that's your problem. If you can't
>> stand being corrected, check your facts before posting.
>
> What misinformation? What correction? I stated a comment based on my own
> experience, and you want to tell me I didn't see what I did in fact
> see?
I'm not telling you that. I'm telling you that you misinterpreted what
you saw, and arrived at an incorrect diagnoses of the problem.
> What makes you so qualified to tell me what my own experiences are?
What makes you unable to have a civil conversation without indulging
in armchair psychology, ad homenem attacks, and straw man arguments?
If you have a logical argument that Mac FTP servers are more prone to
issues than others, and evidence to support it, then I'd really like
to hear it. Seriously! Otherwise this thread is going nowhere, and I'm
done with it.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 04 Jul 2008 23:14:42 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1hcb5ggyl.fsf@dot-app.org>
"Stephan Bour" <sbour@niaid.nih.gov> writes:
> Sherman Pendley wrote:
> } "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> }
> } > Sherman Pendley wrote:
> } > > UnRiel <bdwhite@gmail.com> writes:
> } > >
> } > > > I have a nice PERL script I use to generate CISCO configurations
> } > >
> } > > No need to shout - neither Perl nor Cisco are acronyms.
> } >
> } > I don't think two all-caps words in a sentence that's otherwise
> } > properly cased really constitutes shouting.
> }
> } It's shouting those words.
>
> Nonesense. Obviously you know what he meant by "PERL" and "CICSO", there
> really isn't anything wrong about writing it that way, unless you want to be
> an absolute perfectionist.
A perfectionist would have refused to answer the question based on
that, probably with some unhelpful response like "we talk about Perl
here, not PERL." I just offered a bit of advice I thought the OP might
find useful - and then went on to answer the question.
> } > > Transfer the files in text mode. That will translate the line
> } > > endings as needed.
> } >
> } > While it is common to use ASCII mode one should still take care, as
> } > this isn't always guarenteed to work. There used (still are?) issues
> } > with this when uploading to MacOS based servers, for example.
> }
> } Such as?
>
> I've seen some pretty crazy where file that originally had \r\n ended up
> being \r\n\n, which interestingly, occurred with a version of Serv-U (which
> I recall was fixed in the next release),
That makes sense. If the file was uploaded from a PC in binary mode,
or copied through some other means than FTP, it would have \r\n line
endings. Serv-U was, if I recall correctly, an old-school MacOS
server app, so it would translate its native \r into \r\n, and leave
the \n that's already there alone, resulting in \r\n\n.
It's nice that the next release was enhanced to handle arbitrary line
endings, but I wouldn't really call it a "fix." RFC 959 only requires
the server to translate its native line endings. So, what it was doing
was technically correct behavior, albeit inconvenient and not at all
obvious unless one has read the relevant RFCs.
It's also worth noting that a *nix server could easily have a similar
problem, if it's strictly following the RFC. It would translate the
outgoing \n's though, which would result in \r\r\n being received by
the client instead of \r\n\n.
That's my point in that other thread - this kind of error isn't any
more likely to crop up on Mac servers than others, and more often than
not, what appears to be bizarre behavior is just the server following
the bare minimum requirements of the protocol. I'm not a "Mac guy" who
jumps at the slightest chance to evangelize, but I'll admit that I do
find FUD to be rather annoying, and there appears to be quite a lot of
it floating around where Macs are concerned.
> And while not FTP, I've seen interesting line-terminator situations from web
> forms ,for text coming from a TEXTAREA, though this was probably more the
> fault of server-side scripting that handled the form input, making poor
> assumptions about the incoming data.
No argument there - HTML text areas are a can of worms. Some browsers
use hard wrapping by default, others soft wrapping, some support
nowrap, others don't, etc. It's a real mess - even understanding the
relevant HTML specs doesn't help, because the implementations are all
over the map.
I've taken to simply stripping out all \r's and \n's that come from a
text area as a matter of course, and then rewrapping the text myself
if it needs it. I like to use Text::Wrap for that - it's also useful
for adding a Perl reference to a conversation that's badly in need of
it. :-)
> Either way, it's always prudent to check to make sure a file has transferred
> the way you think it has. If you're uploading to a UNIX-based server, you
> can write a simply script to do a hex-dump of a file. If you see 0D0A when
> you expect 0D, then something went wrong, and you should never assume, when
> dealing with a foreign server you haven't used before, that it will have
> transferred properly and that it needn't be checked.
Indeed. Some servers do (or can, at least) translate any arbitrary
line endings. But you can't rely on that, nor is it entirely accurate
to characterize it as a bug or misconfiguration if they don't - the
relevant RFCs don't require it.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Sat, 5 Jul 2008 04:59:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <k683k5-ksg1.ln1@osiris.mauzo.dyndns.org>
Quoth Sherman Pendley <spamtrap@dot-app.org>:
>
> Seriously! Otherwise this thread is going nowhere, and I'm
> done with it.
Thank you. I, at least, wish you'd reached this point somewhat sooner.
Ben
--
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks] ben@morrow.me.uk
------------------------------
Date: Fri, 4 Jul 2008 21:55:48 -0700
From: "Waylen Gumbal" <wgumgfy@gmail.com>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <6d8d6mF1btesU1@mid.individual.net>
Sherman Pendley wrote:
> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> > Sherman Pendley wrote:
> > > "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> > > > Sherman Pendley wrote:
> > > > >
> > > > > First you claim that a particular OS may have problems,
> > > >
> > > > I never made any such claim.
> > >
> > > Your own words, directly copied and pasted:
> > >
> > > "While it is common to use ASCII mode one should still take care,
> > > as
> > > this isn't always guarenteed to work. There used (still are?)
> > > issues
> > > with this when uploading to MacOS based servers, for example."
> >
> > Yes, as I have run into such issues in the past. I'm still not sure
> > why you are turning a simple comment into a federal investigation.
>
> I asked you a simple question - "Such as?" What's so unreasonable
> about that question? Why are you dodging it? If you know of a specific
> problem with Mac FTP servers, just say so - I use a Mac every day and
> I'd love to know about it.
I wasn't dodging anything. I simply was sharing my experience. I even
todl you before that I don't remember what client or server software it
was, maybe I wasn't clear, but it should be now.
> > > Do you? Then why did you - again, your own words - "attribute the
> > > problem likely was the server wasn't properly telling the client
> > > what sort of platform it was"?
> >
> > Christ, it was a guess.
>
> Then why didn't you say so?
I thought this was clear from the beginning
> Why are you trying to pass off a guess as knowledgable advice?
There you go again, making up your own reality. In the one everyone else
is living in, I simply made a comment and I never tried ot pass it off
as "knowledgable advice" as you claim.
> > > If you actually knew how FTP works, at the protocol level, you
> > > would
> > > know that no server ever tells the client that. It doesn't need
> > > to -
> > > both client and server transforms the text to and from its native
> > > format to ASCII with \r\n for transport. Neither one needs to know
> > > or care about the native format of the other.
> >
> > I never claimed to know how every inch and cm of the FTP protocol,
> > so
> > why are you making this assertion?
>
> Because you claimed to have accurately diagnosed a problem with an
> FTP server. Without a protocol-level understanding of FTP, such a
> claim is pretty hard to swallow.
I never made such a claim. Why must you lie to make your points?
What I did say was that I experienced such a problem as I described, in
effort to share my experience, and you're just turning that completely
upside down.
> > Why are you so obsessed with this?
>
> Why are you trying to paint me as a lunatic
I'm sorry, but I haven't needed to do any of the painting. You've done
that quite well yourself with your unwillingness to discuss civilly and
insistence to act like you're a lawyer.
> > I have been there too, and in many other situations on various
> > platforms. Just because you haven't seen a particular issue doesn't
> > mean it doesn't exist. At least one other poster here has pointed
> > out problem with a particular client that incorrectly converted
> > EOLs, and I've seen many other EOL conversion issues.
>
> Nice straw man. I'm not denying that there can be "issues"; what I'm
> denying is your assertion that they're more common when the server is
> running on a Mac.
I NEVER made such an assetion. I merely used it as an example based on
experiences I've had. It is clear to me you would rather respond in your
offensive-superior tone rather than actually discuss things like two
rational individuals.
--
wg
------------------------------
Date: Sat, 05 Jul 2008 01:48:21 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1ej68rie2.fsf@dot-app.org>
"Waylen Gumbal" <wgumgfy@gmail.com> writes:
> Why must you lie to make your points?
That's it. I've tried to be civil with you, and I'm tired of your
constant attacks and refusal to discuss a technical issue in a
rational manner. Into the killfile you go.
*plonk*
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Sat, 05 Jul 2008 01:50:48 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1abgwri9z.fsf@dot-app.org>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Sherman Pendley <spamtrap@dot-app.org>:
>>
>> Seriously! Otherwise this thread is going nowhere, and I'm
>> done with it.
>
> Thank you. I, at least, wish you'd reached this point somewhat
> sooner.
I always try to give people a chance to discuss things rationally. A
demonstration of hope over experience, I guess. But even the most
optimistic of us has to give up on hopeless trolls eventually.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 04 Jul 2008 21:15:23 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: kill process when file number reached...
Message-Id: <ru52k5xgja.ln2@carpet.zombinet>
John W. Krahn <someone@example.com> wrote:
> Eric Pozharski wrote:
*SKIP*
>> $c = (split m{\s+}, $x)[1];
> split ' ' and split m{\s+} do different things so the list element ()[1]
> may not return the expected result depending on whether there is leading
> whitespace in $x.
I agree, but leading space in B<ps> output would be a big surprise.
--
Torvalds' goal for Linux is very simple: World Domination
------------------------------
Date: Sat, 5 Jul 2008 04:42:19 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sat Jul 5 2008
Message-Id: <K3InqJ.19u6@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
AnyEvent-4.161
http://search.cpan.org/~mlehmann/AnyEvent-4.161/
provide framework for multiple event loops
----
App-FQStat-5.6
http://search.cpan.org/~smueller/App-FQStat-5.6/
Interactive console front-end for Sun's grid engine
----
App-FQStat-5.7
http://search.cpan.org/~smueller/App-FQStat-5.7/
Interactive console front-end for Sun's grid engine
----
App-SVN-Bisect-0.6
http://search.cpan.org/~infinoid/App-SVN-Bisect-0.6/
binary search through svn revisions
----
Archive-Builder-1.14
http://search.cpan.org/~adamk/Archive-Builder-1.14/
File generation and archiving framework
----
CGI-Auth-Auto-1.21
http://search.cpan.org/~leocharre/CGI-Auth-Auto-1.21/
Automatic authentication maintenance and persistence for cgi scrips.
----
CGI-Persistent-1.10
http://search.cpan.org/~vipul/CGI-Persistent-1.10/
Transparent state persistence for CGI applications.
----
CPAN-Reporter-1.16
http://search.cpan.org/~dagolden/CPAN-Reporter-1.16/
Adds CPAN Testers reporting to CPAN.pm
----
Cache-CacheFactory-1.03
http://search.cpan.org/~sgraham/Cache-CacheFactory-1.03/
factory class for Cache::Cache and other modules.
----
Catalyst-Authentication-Credential-OpenID-0.07
http://search.cpan.org/~ashley/Catalyst-Authentication-Credential-OpenID-0.07/
OpenID credential for Catalyst::Plugin::Authentication framework.
----
Catalyst-Controller-WrapCGI-0.0022
http://search.cpan.org/~rkitover/Catalyst-Controller-WrapCGI-0.0022/
Run CGIs in Catalyst
----
Catalyst-Plugin-SmartURI-0.026
http://search.cpan.org/~rkitover/Catalyst-Plugin-SmartURI-0.026/
Configurable URIs for Catalyst
----
Catalyst-View-Email-0.11
http://search.cpan.org/~jshirley/Catalyst-View-Email-0.11/
Send Email from Catalyst
----
Class-Prototyped-Mixin-3
http://search.cpan.org/~tbone/Class-Prototyped-Mixin-3/
Mixin Support for Class::Prototyped
----
Coat-0.331
http://search.cpan.org/~sukria/Coat-0.331/
A light and self-dependent meta-class for Perl5
----
CouchDB-Client-0.01
http://search.cpan.org/~rberjon/CouchDB-Client-0.01/
Simple, correct client for CouchDB
----
CouchDB-Deploy-0.01
http://search.cpan.org/~rberjon/CouchDB-Deploy-0.01/
Simple configuration scripting to deploy CouchDB databases
----
Curses-UI-0.9605
http://search.cpan.org/~mdxi/Curses-UI-0.9605/
A curses based OO user interface framework
----
DBIx-Array-0.01
http://search.cpan.org/~mrdvt/DBIx-Array-0.01/
This modules is a wrapper around DBI with array interfaces
----
DJabberd-Authen-DBI-0.1
http://search.cpan.org/~druoso/DJabberd-Authen-DBI-0.1/
Check users and passwords using a simple sql query
----
Geo-Ellipsoid-1.12
http://search.cpan.org/~jgibson/Geo-Ellipsoid-1.12/
Longitude and latitude calculations using an ellipsoid model.
----
Git-FastExport-0.02
http://search.cpan.org/~book/Git-FastExport-0.02/
A module to parse the output of git-fast-export
----
HTML-TurboForm-0.19
http://search.cpan.org/~camelcase/HTML-TurboForm-0.19/
----
Image-Magick-PixelMosaic-0.03
http://search.cpan.org/~turugina/Image-Magick-PixelMosaic-0.03/
Pixelized mosaic filter for Image::Magick.
----
Imager-QRCode-0.031
http://search.cpan.org/~kurihara/Imager-QRCode-0.031/
Generate QR Code with Imager using libqrencode
----
LWP-Online-1.05
http://search.cpan.org/~adamk/LWP-Online-1.05/
Does your process have access to the web
----
Language-Befunge-4.03
http://search.cpan.org/~jquelin/Language-Befunge-4.03/
a generic funge interpreter
----
Lingua-JA-FindDates-0.001
http://search.cpan.org/~bkb/Lingua-JA-FindDates-0.001/
----
Lingua-JA-FindDates-0.002
http://search.cpan.org/~bkb/Lingua-JA-FindDates-0.002/
----
Math-Goedel-0.03
http://search.cpan.org/~turugina/Math-Goedel-0.03/
Fundamental Goedel number calculator
----
Methods-CheckNames-0.02
http://search.cpan.org/~nuffin/Methods-CheckNames-0.02/
Statically check for named methods
----
Moose-0.54
http://search.cpan.org/~stevan/Moose-0.54/
A postmodern object system for Perl 5
----
Mozilla-Mechanize-GUITester-0.13
http://search.cpan.org/~bosu/Mozilla-Mechanize-GUITester-0.13/
enhances Mozilla::Mechanize with GUI testing.
----
Mozilla-Mechanize-GUITester-0.14
http://search.cpan.org/~bosu/Mozilla-Mechanize-GUITester-0.14/
enhances Mozilla::Mechanize with GUI testing.
----
Muldis-D-0.39.0
http://search.cpan.org/~duncand/Muldis-D-0.39.0/
Formal spec of Muldis D relational DBMS lang
----
Net-BitTorrent-0.025_001
http://search.cpan.org/~sanko/Net-BitTorrent-0.025_001/
BitTorrent peer-to-peer protocol class
----
Net-OAuth-0.12
http://search.cpan.org/~kgrennan/Net-OAuth-0.12/
OAuth protocol support
----
Net-OpenMicroBlogging-0.01
http://search.cpan.org/~kgrennan/Net-OpenMicroBlogging-0.01/
OpenMicroBlogging protocol support
----
NetHack-Item-0.01
http://search.cpan.org/~sartak/NetHack-Item-0.01/
parse and interact with a NetHack item
----
Perl-Critic-1.088
http://search.cpan.org/~elliotjs/Perl-Critic-1.088/
Critique Perl source code for best-practices.
----
Sub-Auto-0.01
http://search.cpan.org/~osfameron/Sub-Auto-0.01/
declare individual handlers for AUTLOADed subs, respecting can and inheritance
----
Sub-Uplevel-0.19_03
http://search.cpan.org/~dagolden/Sub-Uplevel-0.19_03/
apparently run a function in a higher stack frame
----
TAP-Filter-0.02
http://search.cpan.org/~andya/TAP-Filter-0.02/
Filter TAP stream within TAP::Harness
----
TAP-Filter-0.03
http://search.cpan.org/~andya/TAP-Filter-0.03/
Filter TAP stream within TAP::Harness
----
TAP-Harness-Archive-0.10
http://search.cpan.org/~wonko/TAP-Harness-Archive-0.10/
Create an archive of TAP test results
----
Text-Editor-Easy-0.32
http://search.cpan.org/~grommier/Text-Editor-Easy-0.32/
A perl module to edit perl code with syntax highlighting and more.
----
Tk-Wizard-2.138_02
http://search.cpan.org/~lgoddard/Tk-Wizard-2.138_02/
GUI for step-by-step interactive logical process
----
Variable-Magic-0.18
http://search.cpan.org/~vpit/Variable-Magic-0.18/
Associate user-defined magic to variables from Perl.
----
WWW-Spinn3r-2.00200001
http://search.cpan.org/~vipul/WWW-Spinn3r-2.00200001/
An interface to the Spinn3r API (http://www.spinn3r.com)
----
X11-IdleTime-0.07
http://search.cpan.org/~awendt/X11-IdleTime-0.07/
Get the idle time of X11
----
X11-IdleTime-0.08
http://search.cpan.org/~awendt/X11-IdleTime-0.08/
Get the idle time of X11
----
X3D-0.003_002
http://search.cpan.org/~hooo/X3D-0.003_002/
Don't use it. It's in development. For test purposes only!
----
X3D-Values-Int32-0.004_003
http://search.cpan.org/~hooo/X3D-Values-Int32-0.004_003/
Storage type for 32 bit signed integers
----
X3D-Values-Int32-0.004_004
http://search.cpan.org/~hooo/X3D-Values-Int32-0.004_004/
Storage type for 32 bit signed integers
----
XML-Compile-0.87
http://search.cpan.org/~markov/XML-Compile-0.87/
Compilation based XML processing
----
autodie-1.11_01
http://search.cpan.org/~pjf/autodie-1.11_01/
Replace functions with ones that succeed or die with lexical scope
----
podlators-2.1.1
http://search.cpan.org/~rra/podlators-2.1.1/
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Fri, 4 Jul 2008 20:39:20 -0700 (PDT)
From: Todd Wade <waveright@gmail.com>
Subject: Re: Perl CGI utilities?
Message-Id: <a5b76248-92af-438d-8852-52e150a27396@d1g2000hsg.googlegroups.com>
On Jul 1, 10:42 am, JWhite <nowh...@nowhere.com> wrote:
> I have been doing Perl for years, but only as local programming. That is
> to say, I never had any reason to build web pages or other 'Net' stuff.
> Lately I have been playing with CGI on our local network as a way to
> deliver applications without worrying about the OS on the other end. A
> vendor can show up in our mostly Linux shop with a Mac, connect to the
> inhouse server and never know the difference. It works well enough that
> we will be moving a lot of our utilities to CGI.
>
> So it comes back to the fact that I am not a web programmer, yet.
>
> My question, for Perl programmers who are, is what do you use as the
> programming environment? Writing raw CGI into your Perl is great for
> learning, but there is probably a more productive way. I know that there
> isn't a "Perl on Rails" all-in-one type of suite yet, but there must be
> productivity enhancing utilities available.
For your situation I recommend CGI::Application.
It has lots of plugins that handle most things you need to do to get
directly to work on an app's business logic (search CPAN for
CGI::Application::Plugin), and from the description of your
experience, the learning curve should be very shallow.
As an example, here is how easy it is to get first class sessions in
to your application with CGI::App:
http://cgi-app.org/index.cgi?CgiApplicationPluginSessionExample
Catalyst is good (its the best web app framework available in my
opinion), but because you are describing yourself as "not a web
programmer" I suggest starting off with CGI::App and then migrating to
Catalyst when/if you've reached the extent of CGI::App's capabilities.
trwww
------------------------------
Date: Sat, 05 Jul 2008 01:58:36 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Perl CGI utilities?
Message-Id: <m163rkrhwz.fsf@dot-app.org>
Todd Wade <waveright@gmail.com> writes:
> Catalyst is good (its the best web app framework available in my
> opinion), but because you are describing yourself as "not a web
> programmer" I suggest starting off with CGI::App and then migrating to
> Catalyst when/if you've reached the extent of CGI::App's
> capabilities.
Seconded. I'd even go so far as to say that Catalyst is overkill for
nearly anything short of an entire site, even for an experienced web
developer. Although, as you say, if you do happen to be building
something on that scale, IMHO there's really nothing better.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
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 1691
***************************************
