[30230] in Perl-Users-Digest
Perl-Users Digest, Issue: 1473 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 25 16:21:27 2008
Date: Fri, 25 Apr 2008 13:21:20 -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 Fri, 25 Apr 2008 Volume: 11 Number: 1473
Today's topics:
ANNOUNCE: Text-CSV_XS 0.45 <h.m.brand@xs4all.nl>
Apache::AutoIndex - Perl replacment for mod_autoindex <phynkel@gmail.com>
Re: Apache::AutoIndex - Perl replacment for mod_autoind <glex_no-spam@qwest-spam-no.invalid>
Re: Apache::AutoIndex - Perl replacment for mod_autoind <phynkel@gmail.com>
Re: Apache::AutoIndex - Perl replacment for mod_autoind <smallpond@juno.com>
Re: Apache::AutoIndex - Perl replacment for mod_autoind <glex_no-spam@qwest-spam-no.invalid>
Re: Apache::AutoIndex - Perl replacment for mod_autoind xhoster@gmail.com
Re: complete perl-package(IDE, IAprompt etc), where? .c <smallpond@juno.com>
Re: Creating a 'load simulator' by calling Perl Program sheinrich@my-deja.com
Re: DBIx::XML::DataLoader <hjp-usenet2@hjp.at>
Re: DBIx::XML::DataLoader <m@rtij.nl.invlalid>
Re: DBIx::XML::DataLoader <lordofhyphens@gmail.com>
Re: DBIx::XML::DataLoader <lordofhyphens@gmail.com>
Re: EPIC : a very good Perl IDE <dalessio@motorola.NOSPAM.com>
Re: EPIC : a very good Perl IDE <howachen@gmail.com>
Re: FAQ 2.1 What machines support perl? Where do I get <usenet-mail@markshroyer.com>
Re: FAQ 2.1 What machines support perl? Where do I get <brian.d.foy@gmail.com>
Re: FAQ 5.3 How do I count the number of lines in a fil <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 23 Apr 2008 12:59:44 GMT
From: "H.Merijn Brand" <h.m.brand@xs4all.nl>
Subject: ANNOUNCE: Text-CSV_XS 0.45
Message-Id: <Jzs4rt.1zzH@zorch.sf-bay.org>
file: $CPAN/authors/id/H/HM/HMBRAND/Text-CSV_XS-0.45.tgz
size: 88321 bytes
md5: 4a4db0ab2bd727bd5c54c4ed772e358a
2008-04-23 0.45 - H.Merijn Brand <h.m.brand@xs4all.nl>
* Forgot to pack examples/parser-xs.pl
2008-04-23 0.44 - H.Merijn Brand <h.m.brand@xs4all.nl>
* Fixed the error position returned as third arg in error_diag ()
* Made examples/csv-check use this even more vebose
* Removed double-double quote from TODO
* Added examples/parse-xs.pl (attempt to fix bad CSV)
2008-04-21 0.43 - H.Merijn Brand <h.m.brand@xs4all.nl>
* parse errors try to remember failing position
* used valgrind to test for leaks (devel-only)
* used Test::Valgrind as alternative leak check (devel-only)
* improve documentation for error 2023
* nailed the loose quotes in quoted fields
------------------------------
Date: Thu, 24 Apr 2008 13:07:12 -0700 (PDT)
From: Petyr David <phynkel@gmail.com>
Subject: Apache::AutoIndex - Perl replacment for mod_autoindex
Message-Id: <2fdcd4e0-054c-43a6-a671-40acb52530d9@m3g2000hsc.googlegroups.com>
anyone have an experience using this?
The real question:
does using this speed the creation of a directory index in Apache
significantly? We have directories with thousands of small files.
Thanks!
------------------------------
Date: Thu, 24 Apr 2008 16:15:01 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Apache::AutoIndex - Perl replacment for mod_autoindex
Message-Id: <4810f856$0$33225$815e3792@news.qwest.net>
Petyr David wrote:
> anyone have an experience using this?
>
> The real question:
>
> does using this speed the creation of a directory index in Apache
> significantly? We have directories with thousands of small files.
It's more likely that it'll be slower because mod_autoindex is
written in C and compiled into the Apache daemon, you're not
going to get much faster than that.
Possibly you could list 500 at a time, or something, which
would be faster, however having thousands of files in a directory
isn't typically a good design.
------------------------------
Date: Thu, 24 Apr 2008 17:48:48 -0700 (PDT)
From: Petyr David <phynkel@gmail.com>
Subject: Re: Apache::AutoIndex - Perl replacment for mod_autoindex
Message-Id: <6398ce59-eb05-4ac9-9217-f410198f81c6@k37g2000hsf.googlegroups.com>
On Apr 24, 5:15=A0pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
wrote:
> Petyr David wrote:
> > anyone have an experience using this?
>
> > The real question:
>
> > does using this speed the creation of a =A0directory index =A0in Apache
> > significantly? We have directories with thousands of small files.
>
> It's more likely that it'll be slower because mod_autoindex is
> written in C and compiled into the Apache daemon, you're not
> going to get much faster than that.
>
> Possibly you could list 500 at a time, or something, which
> would be faster, however having thousands of files in a directory
> isn't typically a good design.
agreed, but the nature of the data forces us to store the files in
this fashion so there's some sense of meaningfulness: every file is
named and then has a sequential number appended to it - there 64K
potential numbers. we might have to start something like breaking it
into 1000 files/directory.
either way - thanks for your opinion
------------------------------
Date: Fri, 25 Apr 2008 07:12:49 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Apache::AutoIndex - Perl replacment for mod_autoindex
Message-Id: <cb69ec77-cd23-4ae7-b7f6-b1ef0c0d49ae@f63g2000hsf.googlegroups.com>
On Apr 24, 8:48 pm, Petyr David <phyn...@gmail.com> wrote:
> On Apr 24, 5:15 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
> wrote:
>
> > Petyr David wrote:
> > > anyone have an experience using this?
>
> > > The real question:
>
> > > does using this speed the creation of a directory index in Apache
> > > significantly? We have directories with thousands of small files.
>
> > It's more likely that it'll be slower because mod_autoindex is
> > written in C and compiled into the Apache daemon, you're not
> > going to get much faster than that.
>
> > Possibly you could list 500 at a time, or something, which
> > would be faster, however having thousands of files in a directory
> > isn't typically a good design.
>
> agreed, but the nature of the data forces us to store the files in
> this fashion so there's some sense of meaningfulness: every file is
> named and then has a sequential number appended to it - there 64K
> potential numbers. we might have to start something like breaking it
> into 1000 files/directory.
>
> either way - thanks for your opinion
Why not use a real database instead of making one out of a
filesystem? Directory searches are slow, sequential string
compares. Database lookups use fast hash techniques.
------------------------------
Date: Fri, 25 Apr 2008 10:09:31 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Apache::AutoIndex - Perl replacment for mod_autoindex
Message-Id: <4811f42c$0$89393$815e3792@news.qwest.net>
Petyr David wrote:
> On Apr 24, 5:15 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
> wrote:
>> Petyr David wrote:
>>> anyone have an experience using this?
>>> The real question:
>>> does using this speed the creation of a directory index in Apache
>>> significantly? We have directories with thousands of small files.
>> It's more likely that it'll be slower because mod_autoindex is
>> written in C and compiled into the Apache daemon, you're not
>> going to get much faster than that.
>>
>> Possibly you could list 500 at a time, or something, which
>> would be faster, however having thousands of files in a directory
>> isn't typically a good design.
>
> agreed, but the nature of the data forces us to store the files in
> this fashion so there's some sense of meaningfulness: every file is
> named and then has a sequential number appended to it - there 64K
> potential numbers. we might have to start something like breaking it
> into 1000 files/directory.
>
> either way - thanks for your opinion
You could also generate one or more static HTML files, once a day or
whenever new files are added, which would display the filename
and contain a link to the file. Heck, you could probably display
5-10 per line, too. That way you'd avoid having to stat
the thousands of files every time the directory is accessed.
------------------------------
Date: 25 Apr 2008 16:10:24 GMT
From: xhoster@gmail.com
Subject: Re: Apache::AutoIndex - Perl replacment for mod_autoindex
Message-Id: <20080425121025.867$w1@newsreader.com>
smallpond <smallpond@juno.com> wrote:
> On Apr 24, 8:48 pm, Petyr David <phyn...@gmail.com> wrote:
> > On Apr 24, 5:15 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
> > wrote:
> >
> > > Petyr David wrote:
> > > > anyone have an experience using this?
> >
> > > > The real question:
> >
> > > > does using this speed the creation of a directory index in Apache
> > > > significantly? We have directories with thousands of small files.
> >
> > > It's more likely that it'll be slower because mod_autoindex is
> > > written in C and compiled into the Apache daemon, you're not
> > > going to get much faster than that.
> >
> > > Possibly you could list 500 at a time, or something, which
> > > would be faster, however having thousands of files in a directory
> > > isn't typically a good design.
> >
> > agreed, but the nature of the data forces us to store the files in
> > this fashion so there's some sense of meaningfulness: every file is
> > named and then has a sequential number appended to it - there 64K
> > potential numbers. we might have to start something like breaking it
> > into 1000 files/directory.
> >
> > either way - thanks for your opinion
>
> Why not use a real database instead of making one out of a
> filesystem?
Why not use a file system rather than making one out of a database?
Admitted, appending a sequential number to the file name is rather strange,
but that still doesn't mean that he really wants a database rather than a
file system.
> Directory searches are slow, sequential string
> compares.
Not if you already know the exact name of the file. At least, not on any
reasonable file system. They use trees or hashes or something to find the
file quickly.
> Database lookups use fast hash techniques.
Same as reasonable file systems, given an exact name. Of course, if you
are doing globs, or just extracting all entries, then neither file systems
nor databases will use fast hash techniques.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Tue, 22 Apr 2008 15:40:50 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: complete perl-package(IDE, IAprompt etc), where? .com or .org?
Message-Id: <e619456b-dd55-4423-8371-22ab6a1538cc@a70g2000hsh.googlegroups.com>
On Apr 22, 11:49 am, globalrev <skanem...@yahoo.se> wrote:
> is there a complete IDE with an interactive prompt that i can
> download?
> what si the diffrence between perl.com and perl.org? is it the same
> language?
>
> do they include IDEs etc?
perl gets 110,000,000 hits on google, all for the same language.
Although, like the blind men and the elephant, it looks a little
different to everyone who approaches it.
You can get perl for Windows free from ActiveState, who also sell
the best IDE and tools.
http://aspn.activestate.com/ASPN/Perl
There is also a caravan of perl tools on the net, such as:
http://e-p-i-c.sf.net/
http://search.cpan.org/~aepage/Devel-ptkdb-1.1091/ptkdb.pm
------------------------------
Date: Thu, 24 Apr 2008 01:50:38 -0700 (PDT)
From: sheinrich@my-deja.com
Subject: Re: Creating a 'load simulator' by calling Perl Programs - or Forking?
Message-Id: <5b7516bc-191d-4b55-aba6-1456839e93ba@b1g2000hsg.googlegroups.com>
On Apr 4, 6:19 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
wrote:
> sheinr...@my-deja.com wrote:
>
> [...]
>
> > a module that I've written couple of months ago was for that very
> > purpose.
> > Basically your script will have to instantiate anPreforkAgent, tell
> > it how many children to beget (degree of parallelization) and provide
> > it with a couple of callbacks as means of communication.
>
> Hu.. sounds pretty much like Parallel::ForkManager.
Now I got the chance to look at Parallel::ForkManager and get back on
this.
Well, the obvious difference is that PreforkAgent preforks while
Parallel::ForkManager does very much the same as fork(), only limiting
the child number and abstracting waitpid.
And as I wrote above
> > Children will live and be re-used until the job-queue is depleted.
While the Parallel::ForkManager is creating a new process on every job
(with all the performance overhead that involves), PreforkAgent does
no forking once the work 's been taken up and its children do exit
only after the last job was assigned.
The basic incentive for PreforkAgent.pm was making the most efficient
use of the host's ressources. (E. g., to wreak havoc with real big
application servers for the sake of load simulation.)
steffen
------------------------------
Date: Wed, 23 Apr 2008 19:37:58 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: DBIx::XML::DataLoader
Message-Id: <slrng0usvm.5jo.hjp-usenet2@hrunkner.hjp.at>
On 2008-04-15 02:10, Ted <r.ted.byers@rogers.com> wrote:
> I am trying to figure out how to use this package. It looks like it
> may do what I need, and help me write the code more quickly than would
> be the case if I started de novo.
>
> First, although I have been programming in a variety of languages for
> quite a while, i have managed to avoid having to parse XML until now.
> I HATE parsing. I'd rather be implementing a new numeric integration
> algorithm or method for some obscure but interesting statistical
> analysis. But here I am and have to get this done.
>
> The data feed I get appears to be well formed XML, but it is open
> ended in that there is no defined schema. The only information I have
> about what to expect in the XML is provided in the data feed
> provider's documentation. The data structure appears to be very
> simple, but working with it is tedious at best.
>
> Is there a package or utility that can read an XML file of the sort I
> get and create a schema based on what it sees in the data feed file?
>
> In the page for DBIx::XML::DataLoader::MapIt, I see the following:
>
> <XMLtoDB>
> <RootElement name="/Users"/>
> <dbinfo dbuser="user" dbpass="pass"
> dbsource="dbi:mysql:userdata" name="userdata"/>
> <Table name="userinfo" dbname="userdata" xpath="./
> user">
> <KeyColumn name="USER_ID" order="1"/>
> <KeyColumn name="USER_LAST_NAME" order="2"/>
> <KeyColumn name="USER_FIRST_NAME" order="3"/>
> <Element xpath="./id" toColumn="USER_ID"/>
> <Element xpath="./last_name"
> toColumn="USER_LAST_NAME"/>
> <Element xpath="./first_name"
> toColumn="USER_FIRST_NAME"/>
> <Element xpath="./phone_number"
> toColumn="PHONE_NUMBER"/>
> </Table>
> </XMLtoDB>};
>
> Please bear with me for a moment. Am I to understand this is a
> typical example of what a map file looks like? If I understand this
> example correctly, the root element is just the outer most element of
> the XML file to be expected. The dbinfo specifies the login
> credentials to the database, and the database. It isn't clear to me
> though what the name tag is for. Isn't the database specified as the
> last item in the dbsource element? If so, of what value is the name
> element?
I think (just from superficially reading
http://search.cpan.org/~cberning/DBIx-XML-DataLoader-1.1b/DataLoader.pm,
I've never used this module) that you can use it to specify multiple
databases in the same map file. Then you can say "this data goes into
table X on database A, and this goes into table Y on database B". If you
don't need that, just choose a descriptive name.
> I would assume, based on what I see, that this package can
> readily connect to a database implemented within MySQL.
>
> The table element is of most interest. Obviously, I can create a
> suite of tables that correspond to the structure of the XML file.
> Also obviously not all columns in the database are keys or indeces.
> And, I have no idea what XPATH is, let alone what to do with it.
XPath is like Perl. It gets cranky when it's spelt in all upper case
;-).
Seriously: XPath is a language for selecting stuff from an XML file.
Sort of what regexps are for plain text or SQL for relational databases.
You can find the specification at http://www.w3.org/TR/xpath20/ and
google will help you find tutorials (Sorry, I don't have a good one at
hand - you'll probably have to read several of them and the specs, too
to get the hang of it).
> would hazard a guess that the KeyColumn and Element items map elements
> in the XML file to elements in the table in the database.
Seems plausible.
> But it
> isn't clear what I should do with columns that are NOT keys,
Just use an Element without a KeyColumn. Note that the Element element
has two attributes: xpath (which specifies where to find the data in
the XML file) and toColumn (which specifies where to put the data in the
table).
> or what to do when the XML file is hierarchical, with nested elements
> that logically ought to be placed in a different table, and keys
> created to link the tables together (for example, imagine a trivial
> address book that supports peole having multiple addresses, multiple
> email addresses, and multiple phone numbers - or they may well NOT
> have a phone or email).
If the XML file already contains the keys, you can specify them with
xpath. If it doesn't you are probably supposed to create them in a
handler.
hp
------------------------------
Date: Thu, 24 Apr 2008 09:25:25 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: DBIx::XML::DataLoader
Message-Id: <pan.2008.04.24.07.25.24@rtij.nl.invlalid>
On Wed, 23 Apr 2008 19:37:58 +0200, Peter J. Holzer wrote:
> On 2008-04-15 02:10, Ted <r.ted.byers@rogers.com> wrote:
>
>> The table element is of most interest. Obviously, I can create a suite
>> of tables that correspond to the structure of the XML file. Also
>> obviously not all columns in the database are keys or indeces. And, I
>> have no idea what XPATH is, let alone what to do with it.
>
> XPath is like Perl. It gets cranky when it's spelt in all upper case
> ;-).
>
> Seriously: XPath is a language for selecting stuff from an XML file.
> Sort of what regexps are for plain text or SQL for relational databases.
> You can find the specification at http://www.w3.org/TR/xpath20/ and
> google will help you find tutorials (Sorry, I don't have a good one at
> hand - you'll probably have to read several of them and the specs, too
> to get the hang of it).
May I advice the OP to get the O'Reilly XML book? Even if it's not the
solution to his problem, it's money well spend. It explains XPath not
downto all details but good enough to get you going. Once you get it it's
not so hard, but that book is probably the easiest way to get started.
HTH,
M4
------------------------------
Date: Fri, 25 Apr 2008 06:24:28 -0700 (PDT)
From: Lord of Hyphens <lordofhyphens@gmail.com>
Subject: Re: DBIx::XML::DataLoader
Message-Id: <b71a1c48-8d0e-4bc1-8847-8395cf1a28fa@m36g2000hse.googlegroups.com>
On Apr 24, 2:25 am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
> On Wed, 23 Apr 2008 19:37:58 +0200, Peter J. Holzer wrote:
> > On 2008-04-15 02:10, Ted <r.ted.by...@rogers.com> wrote:
>
> >> The table element is of most interest. Obviously, I can create a suite
> >> of tables that correspond to the structure of the XML file. Also
> >> obviously not all columns in the database are keys or indeces. And, I
> >> have no idea what XPATH is, let alone what to do with it.
>
> > XPath is like Perl. It gets cranky when it's spelt in all upper case
> > ;-).
>
> > Seriously: XPath is a language for selecting stuff from an XML file.
> > Sort of what regexps are for plain text or SQL for relational databases.
> > You can find the specification athttp://www.w3.org/TR/xpath20/and
> > google will help you find tutorials (Sorry, I don't have a good one at
> > hand - you'll probably have to read several of them and the specs, too
> > to get the hang of it).
>
> May I advice the OP to get the O'Reilly XML book? Even if it's not the
> solution to his problem, it's money well spend. It explains XPath not
> downto all details but good enough to get you going. Once you get it it's
> not so hard, but that book is probably the easiest way to get started.
>
> HTH,
> M4
The book you're talking about is actually the XSLT book; all of the
xpath query language is in that (I have both).
--LoH
------------------------------
Date: Fri, 25 Apr 2008 06:55:05 -0700 (PDT)
From: Lord of Hyphens <lordofhyphens@gmail.com>
Subject: Re: DBIx::XML::DataLoader
Message-Id: <0ba011a6-5024-4917-acfc-f851bcbc3379@z72g2000hsb.googlegroups.com>
On Apr 25, 8:24 am, Lord of Hyphens <lordofhyph...@gmail.com> wrote:
> On Apr 24, 2:25 am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>
>
>
> > On Wed, 23 Apr 2008 19:37:58 +0200, Peter J. Holzer wrote:
> > > On 2008-04-15 02:10, Ted <r.ted.by...@rogers.com> wrote:
>
> > >> The table element is of most interest. Obviously, I can create a suite
> > >> of tables that correspond to the structure of the XML file. Also
> > >> obviously not all columns in the database are keys or indeces. And, I
> > >> have no idea what XPATH is, let alone what to do with it.
>
> > > XPath is like Perl. It gets cranky when it's spelt in all upper case
> > > ;-).
>
> > > Seriously: XPath is a language for selecting stuff from an XML file.
> > > Sort of what regexps are for plain text or SQL for relational databases.
> > > You can find the specification athttp://www.w3.org/TR/xpath20/and
> > > google will help you find tutorials (Sorry, I don't have a good one at
> > > hand - you'll probably have to read several of them and the specs, too
> > > to get the hang of it).
>
> > May I advice the OP to get the O'Reilly XML book? Even if it's not the
> > solution to his problem, it's money well spend. It explains XPath not
> > downto all details but good enough to get you going. Once you get it it's
> > not so hard, but that book is probably the easiest way to get started.
>
> > HTH,
> > M4
>
> The book you're talking about is actually the XSLT book; all of the
> xpath query language is in that (I have both).
>
> --LoH
Then again, the parent post is probably talking about the handbook, I
was talking about the Pocket Guide (a $10 book).
------------------------------
Date: Tue, 22 Apr 2008 10:11:09 -0500
From: "Mario D'Alessio" <dalessio@motorola.NOSPAM.com>
Subject: Re: EPIC : a very good Perl IDE
Message-Id: <fukvmj$gvg$1@newshost.mot.com>
Thanks for the note. I wasn't aware of it, and
I'm going to give it a try.
Mario
"howa" <howachen@gmail.com> wrote in message
news:ea71f2c2-0c42-4ec6-a238-68601304113f@c19g2000prf.googlegroups.com...
>I am not sure anyone is also using EPIC or not, I just found it today,
> and the I believe this is perhaps one of the the best free Perl editor
> besides komodo edit.
>
> http://e-p-i-c.sourceforge.net/
>
> let's have a try.
>
>
>
> Howard
------------------------------
Date: Wed, 23 Apr 2008 06:30:12 -0700 (PDT)
From: howa <howachen@gmail.com>
Subject: Re: EPIC : a very good Perl IDE
Message-Id: <2c041637-96dc-4dd1-bb83-2237c6b51aa5@l25g2000prd.googlegroups.com>
On 4$B7n(B22$BF|(B, $B2<8a(B11$B;~(B11$BJ,(B, "Mario D'Alessio" <dales...@motorola.NOSPAM.com>
wrote:
> Thanks for the note. I wasn't aware of it, and
> I'm going to give it a try.
>
> Mario
>
Sure, it is very handy for maintaining a large Perl project.
syntax highlighting, code assists, source formating, very solid
features.
------------------------------
Date: Tue, 22 Apr 2008 16:29:45 -0400
From: Mark Shroyer <usenet-mail@markshroyer.com>
Subject: Re: FAQ 2.1 What machines support perl? Where do I get it?
Message-Id: <usenet-mail-263E4C.16294522042008@snap.homestarmy.net>
In article <6cp1e5-cpi.ln1@blue.stonehenge.com>,
PerlFAQ Server <brian@stonehenge.com> wrote:
> 2.1: What machines support perl? Where do I get it?
>
> The standard release of perl (the one maintained by the perl development
> team) is distributed only in source code form. You can find this at
> http://www.cpan.org/src/latest.tar.gz , which is in a standard Internet
> format (a gzipped archive in POSIX tar format).
>
> Perl builds and runs on a bewildering number of platforms. Virtually all
> known and current Unix derivatives are supported (perl's native
> platform), as are other systems like VMS, DOS, OS/2, Windows, QNX, BeOS,
> OS X, MPE/iX and the Amiga.
>
> Binary distributions for some proprietary platforms, including Apple
> systems, can be found http://www.cpan.org/ports/ directory. Because
> these are not part of the standard distribution, they may and in fact do
> differ from the base perl port in a variety of ways. You'll have to
> check their respective release notes to see just what the differences
> are. These differences can be either positive (e.g. extensions for the
> features of the particular platform that are not supported in the source
> release of perl) or negative (e.g. might be based upon a less current
> source release of perl).
The language in the last paragraph is a little confusing, in that it
seems to imply that current Apple users (for the most part, OS X users)
will need to obtain a binary distribution from CPAN.
Maybe this could be improved by saying "including legacy Apple systems"
or "including pre-OS X Apple systems"?
--
Mark Shroyer, http://markshroyer.com/contact/
I have joined others in blocking Google Groups due to excessive
spam. If you want more people to see your posts, you should use
another means of posting to Usenet. http://improve-usenet.org/
------------------------------
Date: Wed, 23 Apr 2008 11:44:40 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 2.1 What machines support perl? Where do I get it?
Message-Id: <230420081144407775%brian.d.foy@gmail.com>
In article <usenet-mail-263E4C.16294522042008@snap.homestarmy.net>,
Mark Shroyer <usenet-mail@markshroyer.com> wrote:
> In article <6cp1e5-cpi.ln1@blue.stonehenge.com>,
> PerlFAQ Server <brian@stonehenge.com> wrote:
>
> > 2.1: What machines support perl? Where do I get it?
> > Binary distributions for some proprietary platforms, including Apple
> > systems, can be found http://www.cpan.org/ports/ directory. Because
> > these are not part of the standard distribution, they may and in fact do
> > differ from the base perl port in a variety of ways. You'll have to
> > check their respective release notes to see just what the differences
> > are. These differences can be either positive (e.g. extensions for the
> > features of the particular platform that are not supported in the source
> > release of perl) or negative (e.g. might be based upon a less current
> > source release of perl).
> Maybe this could be improved by saying "including legacy Apple systems"
> or "including pre-OS X Apple systems"?
I'll just remove the comment about Apple. Thanks, :)
------------------------------
Date: Thu, 24 Apr 2008 14:57:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 5.3 How do I count the number of lines in a file?
Message-Id: <slrng110u4.5jo.hjp-usenet2@hrunkner.hjp.at>
On 2008-04-19 22:05, szr <szrRE@szromanMO.comVE> wrote:
> I don't recall there being any sort of rule saying a text file's last
> character /has/ to be a line terminator, though I can see how it would
> seem better formed if it does.
IEEE Standard 1003.1 (aka POSIX) defines "line" as:
| 3.205 Line
|
| A sequence of zero or more non- <newline>s plus a terminating
| <newline>.
And "text file" as:
| 3.392 Text File
|
| A file that contains characters organized into one or more lines. The
| lines do not contain NUL characters and none can exceed {LINE_MAX}
| bytes in length, including the <newline>. Although IEEE Std
| 1003.1-2001 does not distinguish between text files and binary files
| (see the ISO C standard), many utilities only produce predictable or
| meaningful output when operating on text files. The standard utilities
| that have such restrictions always specify "text files" in their STDIN
| or INPUT FILES sections.
Sinan already mentioned the C standard, but that doesn't specify how
files are represented on disk - a text file could be a series of fixed
or variable length records without any "newline characters" at all, as
long as the stdio library performs the necessary conversions.
hp
------------------------------
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 1473
***************************************
