Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
using Template effectively
21 views
Skip to first unread message
Cal Dershowitz
Aug 21, 2012, 4:27:49 AM8/21/12
to
Hello Newsgroup,
I got my first points on the scoreboard with the badger book:
$ perl destruct1.pl
People of Earth, your attention please.
This is Prostetnic Vogon Jeltz of the
Galactic Hyperspace Planning Council.
As you will no doubt be aware, the plans
for development of the outlying regions
of the Galaxy require the building of a
hyperspatial express route through your
star system, and regrettably your planet
is one of those scheduled for destruction.
The process will take slightly less than
two of your earth minutes.
Thank you.
$ cat destruct1.pl
#!/usr/bin/perl
use strict;
use warnings;
use Template;
use autodie;
my $tt = Template->new();
my $input = 'destruction.tt';
my $vars = {
planet => 'Earth',
captain => 'Prostetnic Vogon Jeltz',
time => 'two of your earth minutes',
};
$tt->process( $input, $vars )
|| die $tt->error();
$
My ubuntu install is new and still a little wobbly, so I'm looking for
the best methods in going forward.
$ perldoc perltidy
You need to install the perl-doc package to use this program.
$ perldoc Template
You need to install the perl-doc package to use this program.
$
Q1) I thought perl-docs came with with the modules. Am I not
downloading them correctly so as to get as much documentation as they
want to give me?
Q2) Is there a nifty perltidy command to get rid of empty lines? What
would a regex look like that does the same thing?
Thanks for your comment,
--
Cal
I got my first points on the scoreboard with the badger book:
$ perl destruct1.pl
People of Earth, your attention please.
This is Prostetnic Vogon Jeltz of the
Galactic Hyperspace Planning Council.
As you will no doubt be aware, the plans
for development of the outlying regions
of the Galaxy require the building of a
hyperspatial express route through your
star system, and regrettably your planet
is one of those scheduled for destruction.
The process will take slightly less than
two of your earth minutes.
Thank you.
$ cat destruct1.pl
#!/usr/bin/perl
use strict;
use warnings;
use Template;
use autodie;
my $tt = Template->new();
my $input = 'destruction.tt';
my $vars = {
planet => 'Earth',
captain => 'Prostetnic Vogon Jeltz',
time => 'two of your earth minutes',
};
$tt->process( $input, $vars )
|| die $tt->error();
$
My ubuntu install is new and still a little wobbly, so I'm looking for
the best methods in going forward.
$ perldoc perltidy
You need to install the perl-doc package to use this program.
$ perldoc Template
You need to install the perl-doc package to use this program.
$
Q1) I thought perl-docs came with with the modules. Am I not
downloading them correctly so as to get as much documentation as they
want to give me?
Q2) Is there a nifty perltidy command to get rid of empty lines? What
would a regex look like that does the same thing?
Thanks for your comment,
--
Cal
Rainer Weikusat
Aug 21, 2012, 8:36:40 AM8/21/12
to
Cal Dershowitz <c...@example.invalid> writes:
[...]
> $ perldoc perltidy
> You need to install the perl-doc package to use this program.
[...]
> Q1) I thought perl-docs came with with the modules. Am I not
> downloading them correctly so as to get as much documentation as they
> want to give me?
perl-doc is a package containing the documentation bundled with the
perl core and the perldoc program. So why don't you just install it
when being asked to?
[...]
> $ perldoc perltidy
> You need to install the perl-doc package to use this program.
> Q1) I thought perl-docs came with with the modules. Am I not
> downloading them correctly so as to get as much documentation as they
> want to give me?
perl core and the perldoc program. So why don't you just install it
when being asked to?
Ben Morrow
Aug 21, 2012, 10:10:44 AM8/21/12
to
Quoth Cal Dershowitz <c...@example.invalid>:
> Hello Newsgroup,
>
> I got my first points on the scoreboard with the badger book:
I don't wish to be rude, but what made you think anyone was interested?
>
> I got my first points on the scoreboard with the badger book:
The first section of your post appears to be completely irrelevant.
> My ubuntu install is new and still a little wobbly, so I'm looking for
> the best methods in going forward.
>
> $ perldoc perltidy
> You need to install the perl-doc package to use this program.
> $ perldoc Template
> You need to install the perl-doc package to use this program.
> $
>
> Q1) I thought perl-docs came with with the modules. Am I not
> downloading them correctly so as to get as much documentation as they
> want to give me?
into several packages. You will need to locate and install them all to
get a properly-functioning perl install. Going from the information on
packages.debian.org, it looks like you need
libcgi-fast-perl
libperl-dev
libperl5.14
perl-base
perl-doc
perl-modules
but it's very hard to be sure; I don't know if Ubuntu is the same or
not.
> Q2) Is there a nifty perltidy command to get rid of empty lines? What
> would a regex look like that does the same thing?
Or do something equivalent in your editor.
Ben
Ben Morrow
Aug 21, 2012, 11:13:31 AM8/21/12
to
Quoth Ben Morrow <b...@morrow.me.uk>:
>
> Linux distributions have a very nasty habit of splitting the perl core
> into several packages. You will need to locate and install them all to
> get a properly-functioning perl install. Going from the information on
> packages.debian.org, it looks like you need
>
> libcgi-fast-perl
> libperl-dev
> libperl5.14
> perl-base
> perl-doc
> perl-modules
A correction: it looks like you need
> Linux distributions have a very nasty habit of splitting the perl core
> into several packages. You will need to locate and install them all to
> get a properly-functioning perl install. Going from the information on
> packages.debian.org, it looks like you need
>
> libcgi-fast-perl
> libperl-dev
> libperl5.14
> perl-base
> perl-doc
> perl-modules
perl
as well. I was under the impression perl-base and perl were
alternatives, but apparently you need both.
Ben
Rainer Weikusat
Aug 21, 2012, 11:37:08 AM8/21/12
to
Ben Morrow <b...@morrow.me.uk> writes:
[...]
> Linux distributions have a very nasty habit of splitting the perl core
> into several packages. You will need to locate and install them all to
> get a properly-functioning perl install.
The opposite of this statement, "perl developers have the nasty habit
of aggegrating all kinds of technically unrelated or only losely
related stuff into a single tarball. Depending on your needs, large
parts of that may be omitted from any properly functioning perl
install", is - of course - just as true or as false.
[...]
> Linux distributions have a very nasty habit of splitting the perl core
> into several packages. You will need to locate and install them all to
> get a properly-functioning perl install.
of aggegrating all kinds of technically unrelated or only losely
related stuff into a single tarball. Depending on your needs, large
parts of that may be omitted from any properly functioning perl
install", is - of course - just as true or as false.
Peter J. Holzer
Aug 21, 2012, 2:42:24 PM8/21/12
to
On 2012-08-21 15:13, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Ben Morrow <b...@morrow.me.uk>:
>> Linux distributions have a very nasty habit of splitting the perl core
>> into several packages. You will need to locate and install them all to
>> get a properly-functioning perl install.
Fortunately the error message clearly told Cal the name of the missing
> Quoth Ben Morrow <b...@morrow.me.uk>:
>> Linux distributions have a very nasty habit of splitting the perl core
>> into several packages. You will need to locate and install them all to
>> get a properly-functioning perl install.
package, so locating and installing it shouldn't be that hard.
>> Going from the information on
>> packages.debian.org, it looks like you need
>>
>> libcgi-fast-perl
>> libperl-dev
>> libperl5.14
>> perl-base
>> perl-doc
>> perl-modules
>
> A correction: it looks like you need
>
> perl
>
> as well. I was under the impression perl-base and perl were
> alternatives, but apparently you need both.
(it includes only /usr/bin/perl and the most essential core packages)
while perl contains the rest of the core (some of it indirectly through
perl-modules) except the documentation. So if you want to run perl
programs you normally install perl (which sucks in perl-base,
perl-modules and a lot of other stuff through dependencies) and if you
want to develop perl programs you install perl and perl-doc.
I don't think you need libperl5.14 or libperl-dev unless you want to
embed perl in another program. And of course you only need
libcgi-fast-perl if you want to use FastCGI (which doesn't seem to be
the case here but maybe Cal has mentioned it in another thread).
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org
Ben Morrow
Aug 21, 2012, 4:56:21 PM8/21/12
to
Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
>
> I don't think you need libperl5.14 or libperl-dev unless you want to
> embed perl in another program.
Looking again, that's correct, and *really* confusing. Except on i386,
> I don't think you need libperl5.14 or libperl-dev unless you want to
> embed perl in another program.
perl-base installs libperl.so.5.14, in the wrong place, and libperl5.14
installs nothing useful at all; on i386, perl-base installs a
statically-linked /usr/bin/perl and libperl5.14 installs a
libperl.so.5.14 (still in the wrong place), which /usr/bin/perl does not
link, but presumably other perl-embedding systems do. Presumably this
also means that on i386 /usr/bin/perl reports $Config{useshrplib} as
false, but there is in fact a libperl.so, which will *still* (I think)
report $Config{useshrplib} as false, since it presumably loads the same
Config.pm.
libperl-dev installs libperl.a and libperl.so (presumably a symlink
rather than a real library?) which are usually only needed to embed
perl; libperl.a is also used to install statically-linked XS modules, but
that's almost never done nowadays except for DynaLoader, which is built
at perl install time.
> And of course you only need
> libcgi-fast-perl if you want to use FastCGI (which doesn't seem to be
> the case here but maybe Cal has mentioned it in another thread).
modules can quite reasonably assume it will be there without declaring
an explicit dependancy. IMHO anything less than 'everything installed by
a normal manual perl install' is risky, unless you will only be using
perl to run things installed from packages (which have presumably been
tested against the various minimal options, and declare their detailed
dependancies properly).
At which point I have to ask: what on Earth is all this supposed to
achieve? A space saving of a few MB, at the cost of leaving users who
don't know all these details with an incomplete mess that can't be
trusted to run anything that hasn't been specifically tested against
that environment? Doesn't seem like a good deal, to me.
Ben
Rainer Weikusat
Aug 21, 2012, 5:18:38 PM8/21/12
to
[...]
>> And of course you only need libcgi-fast-perl if you want to use
>> FastCGI (which doesn't seem to be the case here but maybe Cal has
>> mentioned it in another thread).
>
> Well, CGI::Fast has been part of the core forever (since 5004), so CPAN
> modules can quite reasonably assume it will be there without declaring
> an explicit dependancy.
CPAN modules have been developed with a specific, packaged perl
distribution in mind (and its not that this specific packaged perl
distribution wouldn't change) ...
> IMHO anything less than 'everything installed by a normal manual
> perl install' is risky, unless you will only be using perl to run
> things installed from packages
... and installing modules packaged for this specific distribution
might require additional work when they are supposed to be used with
other distributions.
> At which point I have to ask: what on Earth is all this supposed to
> achieve? A space saving of a few MB, at the cost of leaving users who
> don't know all these details with an incomplete mess that can't be
> trusted to run anything that hasn't been specifically tested against
> that environment?
Actually, no software downloaded from some random location on the
internet, including random other 'software distribution point' can be
'trusted to run' on a system it wasn't tested with. That's why users
of 'Linux distributions' are usually encouraged to stick to software
packaged for their distribution --- it has been tested with it, is
actually considered to be sufficiently bug free for a general release
and there's a 'well-known address' for dealing with bugs, as opposed
fiftythousand e-mail addresses distributed throughout a labyrinth of
four times as many web pages, half of which used to be used by people
who meanwhile died.
>> And of course you only need libcgi-fast-perl if you want to use
>> FastCGI (which doesn't seem to be the case here but maybe Cal has
>> mentioned it in another thread).
>
> Well, CGI::Fast has been part of the core forever (since 5004), so CPAN
> modules can quite reasonably assume it will be there without declaring
> an explicit dependancy.
distribution in mind (and its not that this specific packaged perl
distribution wouldn't change) ...
> IMHO anything less than 'everything installed by a normal manual
> perl install' is risky, unless you will only be using perl to run
> things installed from packages
might require additional work when they are supposed to be used with
other distributions.
> At which point I have to ask: what on Earth is all this supposed to
> achieve? A space saving of a few MB, at the cost of leaving users who
> don't know all these details with an incomplete mess that can't be
> trusted to run anything that hasn't been specifically tested against
> that environment?
internet, including random other 'software distribution point' can be
'trusted to run' on a system it wasn't tested with. That's why users
of 'Linux distributions' are usually encouraged to stick to software
packaged for their distribution --- it has been tested with it, is
actually considered to be sufficiently bug free for a general release
and there's a 'well-known address' for dealing with bugs, as opposed
fiftythousand e-mail addresses distributed throughout a labyrinth of
four times as many web pages, half of which used to be used by people
who meanwhile died.
Peter J. Holzer
Aug 21, 2012, 5:48:50 PM8/21/12
to
On 2012-08-21 20:56, Ben Morrow <b...@morrow.me.uk> wrote:
> At which point I have to ask: what on Earth is all this supposed to
> achieve? A space saving of a few MB,
About 50 MB, actually, which is about 1/4 of the size of a minimal
> At which point I have to ask: what on Earth is all this supposed to
> achieve? A space saving of a few MB,
Debian installation. Given the choice between increasing this size by
25% or replacing every perl perl essential perl script by one in a
different language, most Debian developers would probably prefer the
latter. Much of this is historical, of course, but there are still
embedded systems with very little space.
> at the cost of leaving users who don't know all these details with an
> incomplete mess that can't be trusted to run anything that hasn't been
> specifically tested against that environment?
libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
module shouldn't even try to use CPAN. He's almost guaranteed to trip
over the first module which includes some XS code.
Ben Morrow
Aug 21, 2012, 6:54:33 PM8/21/12
to
> On 2012-08-21 20:56, Ben Morrow <b...@morrow.me.uk> wrote:
> > At which point I have to ask: what on Earth is all this supposed to
> > achieve? A space saving of a few MB,
>
> About 50 MB, actually, which is about 1/4 of the size of a minimal
> Debian installation. Given the choice between increasing this size by
> 25% or replacing every perl perl essential perl script by one in a
> different language, most Debian developers would probably prefer the
> latter. Much of this is historical, of course, but there are still
> embedded systems with very little space.
I don't actually have much of a problem with Debian splitting the perl
> > At which point I have to ask: what on Earth is all this supposed to
> > achieve? A space saving of a few MB,
>
> About 50 MB, actually, which is about 1/4 of the size of a minimal
> Debian installation. Given the choice between increasing this size by
> 25% or replacing every perl perl essential perl script by one in a
> different language, most Debian developers would probably prefer the
> latter. Much of this is historical, of course, but there are still
> embedded systems with very little space.
distribution for their own internal use, provided they are prepared to
deal with the consequences. But 'apt-get install perl' should install a
complete perl distribution, including everything, in way which is
consistent with the installed Config.pm. Otherwise we just get people
reporting bugs to p5p and CPAN modules which are actually caused by
Debian packaging incompatibilities. (None of this is specific to Debian,
of course, nor to Linux; ActiveState have been guilty of the same tricks
from time to time.)
> > at the cost of leaving users who don't know all these details with an
> > incomplete mess that can't be trusted to run anything that hasn't been
> > specifically tested against that environment?
>
> Frankly, anyone who can't be bothered to type "apt-get install
> libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
> module shouldn't even try to use CPAN. He's almost guaranteed to trip
> over the first module which includes some XS code.
loudly print 'DO NOT USE THIS. USE .debS INSTEAD, OR BUILD YOUR OWN
PERL.' every time it's used, and should document somewhere appropriate
and obvious that the perl package is not entirely compatible with a
standard perl install, and should not be used for normal Perl
development.
Ben
Rainer Weikusat
Aug 21, 2012, 8:51:40 PM8/21/12
to
>> Frankly, anyone who can't be bothered to type "apt-get install
>> libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
>> module shouldn't even try to use CPAN. He's almost guaranteed to trip
>> over the first module which includes some XS code.
>
> In which case the Debian package should include a CPAN.pm modified to
> loudly print 'DO NOT USE THIS. USE .debS INSTEAD, OR BUILD YOUR OWN
> PERL.' every time it's used,
That would be rather annoying, given that some people use cpan because
>> libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
>> module shouldn't even try to use CPAN. He's almost guaranteed to trip
>> over the first module which includes some XS code.
>
> In which case the Debian package should include a CPAN.pm modified to
> loudly print 'DO NOT USE THIS. USE .debS INSTEAD, OR BUILD YOUR OWN
> PERL.' every time it's used,
they need or want to, not just because they've been tricked into doing
it for no good reason ...
Mart van de Wege
Aug 22, 2012, 3:49:50 AM8/22/12
to
Ben Morrow <b...@morrow.me.uk> writes:
> But 'apt-get install perl' should install a complete perl
> distribution, including everything, in way which is consistent with
> the installed Config.pm.
It does. 'perl' drags in 'perl-modules' as well, giving a complete perl
> But 'apt-get install perl' should install a complete perl
> distribution, including everything, in way which is consistent with
> the installed Config.pm.
install.
It *doesn't* pull in perl-doc by default, but anyone installing Debian
*should* known that Debian doesn't auto-install documentation packages
anyway.
Of course, anyone installing Ubuntu is not supposed to worry about that,
but that's *Ubuntu's* fault, for not patching their packages for this
use case.
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
Eric Pozharski
Aug 22, 2012, 2:41:57 AM8/22/12
to
with <96gdg9-...@anubis.morrow.me.uk> Ben Morrow wrote:
*SKIP* [[ jeez ]]
Then,.. I assume, you propos to raid debian, or something?
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
*SKIP* [[ jeez ]]
Then,.. I assume, you propos to raid debian, or something?
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
Cal Dershowitz
Aug 22, 2012, 11:38:45 PM8/22/12
to
time to do these manually again. If I wanted to make it a part of a
tool-chain that I invoke the next time I start from square one, how
would I do it?
I could write a script that has
read helpfile into a hash
my $stat = system "sudo apt-get install {$hash{$key}}";
Q1) Can I redirect STDOUT to a text file so as to see terminal output on
this?
$ sudo apt-get install perl
[sudo] password for fred:
Reading package lists... Done
Building dependency tree
Reading state information... Done
perl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 25 not upgraded.
$ cd /home/fred/Desktop/scripts/
$ cat perl_lib_list.txt
libcgi-fast-perl
libperl-dev
libperl5.14
perl-base
perl-doc
perl-modules
perl
libperl-dev
libperl5.14
perl-base
perl-doc
perl-modules
$
Q2) 25 whats are not upgraded. Are there 25 other things that have
something to do with perl?
I'll just keep on working my way up the list.
--
Cal
Cal Dershowitz
Aug 22, 2012, 11:45:08 PM8/22/12
to
On 08/22/2012 09:38 PM, Cal Dershowitz wrote:
> perl-base
> perl-doc
> perl-modules
> perl
> $
>
> Q2) 25 whats are not upgraded. Are there 25 other things that have
> something to do with perl?
>
> I'll just keep on working my way up the list.
$ sudo apt-get install perl-modules
> perl-base
> perl-doc
> perl-modules
> perl
> $
>
> Q2) 25 whats are not upgraded. Are there 25 other things that have
> something to do with perl?
>
> I'll just keep on working my way up the list.
[sudo] password for fred:
Reading package lists... Done
Building dependency tree
Reading state information... Done
perl-modules is already the newest version.
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 25 not upgraded.
$ sudo apt-get install perl-base
Reading package lists... Done
Building dependency tree
Reading state information... Done
perl-base is already the newest version.
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 25 not upgraded.
$
My guess is that the 25 has something to do with libraries that have
$
perl and then a dash in their names.
--
Cal
Cal Dershowitz
Aug 22, 2012, 11:57:42 PM8/22/12
to
$ sudo apt-get install libcgi-fast-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
Building dependency tree
Reading state information... Done
libfcgi-perl
The following NEW packages will be installed:
libcgi-fast-perl libfcgi-perl
0 upgraded, 2 newly installed, 0 to remove and 25 not upgraded.
Need to get 66.4 kB of archives.
After this operation, 310 kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
Get:1 http://us.archive.ubuntu.com/ubuntu/ precise/universe libfcgi-perl
i386 0.74-1build1 [36.6 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ precise-updates/universe
libcgi-fast-perl all 5.14.2-6ubuntu2.1 [29.8 kB]
Fetched 66.4 kB in 0s (98.1 kB/s)
Selecting previously unselected package libfcgi-perl.
(Reading database ... 182246 files and directories currently installed.)
Unpacking libfcgi-perl (from .../libfcgi-perl_0.74-1build1_i386.deb) ...
Selecting previously unselected package libcgi-fast-perl.
Unpacking libcgi-fast-perl (from
.../libcgi-fast-perl_5.14.2-6ubuntu2.1_all.deb) ...
Processing triggers for man-db ...
Setting up libfcgi-perl (0.74-1build1) ...
Setting up libcgi-fast-perl (5.14.2-6ubuntu2.1) ...
$
--
Cal
Cal Dershowitz
Aug 23, 2012, 12:08:44 AM8/23/12
to
On 08/21/2012 03:48 PM, Peter J. Holzer wrote:
> On 2012-08-21 20:56, Ben Morrow <b...@morrow.me.uk> wrote:
>> At which point I have to ask: what on Earth is all this supposed to
>> achieve? A space saving of a few MB,
>
> About 50 MB, actually, which is about 1/4 of the size of a minimal
> Debian installation. Given the choice between increasing this size by
> 25% or replacing every perl perl essential perl script by one in a
> different language, most Debian developers would probably prefer the
> latter. Much of this is historical, of course, but there are still
> embedded systems with very little space.
>
>> at the cost of leaving users who don't know all these details with an
>> incomplete mess that can't be trusted to run anything that hasn't been
>> specifically tested against that environment?
>
> Frankly, anyone who can't be bothered to type "apt-get install
> libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
> module shouldn't even try to use CPAN. He's almost guaranteed to trip
> over the first module which includes some XS code.
Ouwa, peter, I understand the criticism, but from my perspective it's
> On 2012-08-21 20:56, Ben Morrow <b...@morrow.me.uk> wrote:
>> At which point I have to ask: what on Earth is all this supposed to
>> achieve? A space saving of a few MB,
>
> About 50 MB, actually, which is about 1/4 of the size of a minimal
> Debian installation. Given the choice between increasing this size by
> 25% or replacing every perl perl essential perl script by one in a
> different language, most Debian developers would probably prefer the
> latter. Much of this is historical, of course, but there are still
> embedded systems with very little space.
>
>> at the cost of leaving users who don't know all these details with an
>> incomplete mess that can't be trusted to run anything that hasn't been
>> specifically tested against that environment?
>
> Frankly, anyone who can't be bothered to type "apt-get install
> libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
> module shouldn't even try to use CPAN. He's almost guaranteed to trip
> over the first module which includes some XS code.
almost impossible to discern context on most of this.
Q1) What warning/error would I have seen in order to know that I didn't
have whatever comes with perl, and in this context, I don't mean perl
the language or perl the interpreter. Not perl the library. Apparently
it's perl the module.
--
Cal
Cal Dershowitz
Aug 23, 2012, 12:26:12 AM8/23/12
to
On 08/22/2012 01:49 AM, Mart van de Wege wrote:
> Ben Morrow <b...@morrow.me.uk> writes:
>
>> But 'apt-get install perl' should install a complete perl
>> distribution, including everything, in way which is consistent with
>> the installed Config.pm.
>
> It does. 'perl' drags in 'perl-modules' as well, giving a complete perl
> install.
>
> It *doesn't* pull in perl-doc by default, but anyone installing Debian
> *should* known that Debian doesn't auto-install documentation packages
> anyway.
>
> Of course, anyone installing Ubuntu is not supposed to worry about that,
> but that's *Ubuntu's* fault, for not patching their packages for this
> use case.
>
>
aha, martin, maybe this is the answer you referred to.
> Ben Morrow <b...@morrow.me.uk> writes:
>
>> But 'apt-get install perl' should install a complete perl
>> distribution, including everything, in way which is consistent with
>> the installed Config.pm.
>
> It does. 'perl' drags in 'perl-modules' as well, giving a complete perl
> install.
>
> It *doesn't* pull in perl-doc by default, but anyone installing Debian
> *should* known that Debian doesn't auto-install documentation packages
> anyway.
>
> Of course, anyone installing Ubuntu is not supposed to worry about that,
> but that's *Ubuntu's* fault, for not patching their packages for this
> use case.
>
>
--
Cal
Peter J. Holzer
Aug 23, 2012, 4:09:55 AM8/23/12
to
message you quoted was:
| You need to install the perl-doc package to use this program.
apt-get install perl-doc
(instead of apt-get you can of course use aptitude or the Ubuntu
Software Center or whatever your favourite way to install packages is).
In this case you don't even have to guess because it tells you exactly
what to do.
But this isn't what the last few messages were about. Ben was
complaining that some core modules (actually only one, CGI::Fast) are
not installed automatically when you install the "perl" package.
While this is strange (I have no idea why CGI::Fast was singled out) I
really don't think that it makes any difference: The package name
follows the same convention as for (almost) all non-core modules, so
when you try to run a FastCGI script and get an error message
Can't locate CGI/Fast.pm in @INC (@INC contains: ...)
you just invoke
apt-get install libcgi-fast-perl
just as you would invoke
apt-get install libtemplate-perl
if you got the message
Can't locate Template.pm in @INC (@INC contains: ...)
You really don't have to know or care that CGI::Fast is a core module
(in fact I didn't know that until this thread, although I've been using
it for years: If it's already installed in system that's nice, and if
it isn't installed, I know how to install it)
If you are going to administrate a Debian (or Ubuntu) system, you will
need a basic understanding of the Debian packaging system. There is no
way around that. And if you are going to use CPAN on a Debian/Ubuntu
system, you will need that, too. Because some packages on CPAN need
header files to compile and libraries to link against, and you will need
to know how to find and install the necessary development packages.
That was why I wrote that anybody who couldn't install CGI::Fast with
apt-get should steer clear of CPAN. If you know enough about Debian to
install arbitrary packages (either from the distribution repository or
CPAN), you won't even notice anything special about CGI::Fast. And if
you can't install CGI::Fast on a Debian system, you won't be able to
install any non-core module from the Debian repository or any module
which needs to compile something from CPAN, either. So the fact that
CGI::Fast is in a separate package is IMHO just a puzzling oddity, it
doesn't turn perl into an "incomplete mess".
> and in this context, I don't mean perl the language or perl the
> interpreter. Not perl the library. Apparently it's perl the module.
Rainer Weikusat
Aug 23, 2012, 5:30:07 AM8/23/12
to
Cal Dershowitz <c...@example.invalid> writes:
> On 08/21/2012 03:48 PM, Peter J. Holzer wrote:
[...]
> On 08/21/2012 03:48 PM, Peter J. Holzer wrote:
>> Frankly, anyone who can't be bothered to type "apt-get install
>> libfoo-bar-perl" when a perl script complains about a missing Foo::Bar
>> module shouldn't even try to use CPAN. He's almost guaranteed to trip
>> over the first module which includes some XS code.
>
> Ouwa, peter, I understand the criticism, but from my perspective it's
> almost impossible to discern context on most of this.
>
> Q1) What warning/error would I have seen in order to know that I
> didn't have whatever comes with perl, and in this context, I don't
> mean perl the language or perl the interpreter. Not perl the library.
> Apparently it's perl the module.
Can't locate NoSuchModule.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
That's an example of an error you get when some Perl code attempts to
use a module which isn't available. In this case, the obvious solution
is to install the missing module. As per Debian naming convention
(probably also used by Ubuntu) for that, a package providing a Perl
module named NoSuchModule should be called libnosuchmodule-perl.
0 new messages