[32500] in Perl-Users-Digest
Perl-Users Digest, Issue: 3765 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 23 06:09:16 2012
Date: Thu, 23 Aug 2012 03:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 23 Aug 2012 Volume: 11 Number: 3765
Today's topics:
Re: magic installation woes [OT] <cal@example.invalid>
Re: magic installation woes [OT] (Tim McDaniel)
Re: magic installation woes [OT] <arjenbax@googlemail.com>
Re: magic installation woes [OT] <rweikusat@mssgmbh.com>
Two remarks about the Perl object model <rweikusat@mssgmbh.com>
Re: undefine @array <ben@morrow.me.uk>
Re: undefine @array <ben@morrow.me.uk>
Re: using Template effectively <cal@example.invalid>
Re: using Template effectively <cal@example.invalid>
Re: using Template effectively <cal@example.invalid>
Re: using Template effectively <cal@example.invalid>
Re: using Template effectively <cal@example.invalid>
Re: using Template effectively <hjp-usenet2@hjp.at>
Re: using Template effectively <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 22 Aug 2012 21:15:14 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: magic installation woes [OT]
Message-Id: <cuidnT6tSJ3fPajNnZ2dnUVZ_qydnZ2d@supernews.com>
On 08/21/2012 04:07 AM, Cal Dershowitz wrote:
> On 08/19/2012 11:31 PM, Cal Dershowitz wrote:
>>
>> Since you were missing a library named MagickCore and a header of the
>> same name, the candidate suggesting itself would be libmagickcore-dev.
>> You can install that with
>>
>> apt-get install libmagickcore-dev
>
>
> $ sudo apt-get install libmagickcore-dev
> [sudo] password for fred:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> libmagickcore-dev is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
> $
>
> This is encouraging for me, because I've got 99 problems, and this is no
> longer one of them.
, he said, without successful output.
fred@fred-desktop:~/Desktop$ sudo apt-get install imagemagick
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libmagickwand4 libnetpbm10 netpbm
Suggested packages:
imagemagick-doc autotrace curl enscript ffmpeg gnuplot grads hp2xx
html2ps
libwmf-bin mplayer povray radiance texlive-base-bin transfig ufraw-batch
The following NEW packages will be installed:
imagemagick libmagickwand4 libnetpbm10 netpbm
0 upgraded, 4 newly installed, 0 to remove and 12 not upgraded.
Need to get 1,611 kB of archives.
After this operation, 5,030 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
...
Q1) What does it mean to be "processing triggers?"
Processing triggers for man-db ...
Setting up libmagickwand4 (8:6.6.9.7-5ubuntu3.1) ...
Setting up imagemagick (8:6.6.9.7-5ubuntu3.1) ...
Setting up libnetpbm10 (2:10.0-15) ...
Setting up netpbm (2:10.0-15) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Q2) What's that now? ^^^^
fred@fred-desktop:~/Desktop$
------------------------------
Date: Thu, 23 Aug 2012 04:23:47 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: magic installation woes [OT]
Message-Id: <k14b8j$a8q$1@reader1.panix.com>
In article <cuidnT6tSJ3fPajNnZ2dnUVZ_qydnZ2d@supernews.com>,
Cal Dershowitz <cal@example.invalid> wrote:
>Q1) What does it mean to be "processing triggers?"
>
>Processing triggers for man-db ...
>Setting up libmagickwand4 (8:6.6.9.7-5ubuntu3.1) ...
>Setting up imagemagick (8:6.6.9.7-5ubuntu3.1) ...
>Setting up libnetpbm10 (2:10.0-15) ...
>Setting up netpbm (2:10.0-15) ...
>Processing triggers for libc-bin ...
>ldconfig deferred processing now taking place
>
>Q2) What's that now? ^^^^
It is, so far as I have ever seen, normal (if verbose) output
explaining what normal and successful steps are being done at each
point. I saw them hundreds of times while successfully updating
packages. In sum, I don't know and it doesn't matter. If you repeat
the command, you should see that it has 0 packages to install; if you
look at the packages installed on your system, the list should include
the one(s) on your previous command line.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 23 Aug 2012 01:58:29 -0700 (PDT)
From: ilovelinux <arjenbax@googlemail.com>
Subject: Re: magic installation woes [OT]
Message-Id: <a81fa314-ab14-4990-87ff-fb3c8b98ee6f@googlegroups.com>
23-AUG-2012 05:15:14 UTC+2 Cal Dershowitz wrote:
> Q1) What does it mean to be "processing triggers?"
>=20
>=20
> Processing triggers for man-db ...
> Setting up libmagickwand4 (8:6.6.9.7-5ubuntu3.1) ...
> Setting up imagemagick (8:6.6.9.7-5ubuntu3.1) ...
> Setting up libnetpbm10 (2:10.0-15) ...
> Setting up netpbm (2:10.0-15) ...
> Processing triggers for libc-bin ...
> ldconfig deferred processing now taking place
>=20
> Q2) What's that now? ^^^^
Q1) As far as I have understood, triggers are an extension of the Debian pa=
ckage system that allows multiple packages to share the same post-install (=
postinst) actions.
Some actions, like updating the whatis database (http://linux.die.net/man/8=
/makewhatis), are part the postinst script of a lot of packages, but only t=
he last action is effective. Instead of performing the action again and aga=
in for each package, a package may register a trigger. The trigger will be =
performed only once at the end of the installation process. This may result=
in a huge time gain.
Q2) ldconfig is a means to specify to the dynaloader of the Linux kernel in=
which directories to search for shared object libraries. See http://linux.=
die.net/man/8/ldconfig.
HTH
------------------------------
Date: Thu, 23 Aug 2012 10:47:21 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: magic installation woes [OT]
Message-Id: <871uiy3pp2.fsf@sapphire.mobileactivedefense.com>
Cal Dershowitz <cal@example.invalid> writes:
[...]
> Q1) What does it mean to be "processing triggers?"
[...]
> Processing triggers for libc-bin ...
> ldconfig deferred processing now taking place
>
> Q2) What's that now? ^^^^
Please consider to stop crossposting general Linux-related questions
to completely unrelated newsgroups.
Answer: One part of the installation of a Debian package is running
the so-called 'postinstall' script. As the name might suggest, this
script runs after all files the package is composed of have been
installed. Its purpose is to configure whatever needs to be configured
in order to integrate the package into the system. One example of this
is what the 'ldconfig deferred processing' refers to: Shared libraries
can be installed in any number of different filesystem locations (in
the most simple case, the system uses /lib and /usr/lib). Whenever a
process using a particular shared library needs to be started, the
file corresponding with this libray needs to be loaded in addition to
the file containing the main program (simplification). Often, the same
library is used by many running processes (eg, the C library is used
by all of them). In order to avoid searching the filesystem for the
same file still residing in the same location over and over again, the
system maintains a cache which records the location of all installed
shared libraries. Whenever a new shared library is installed, this
cache needs to be updated so that the runtime linker knows where to
find he corresponding file. This is accomplished by running the
ldconfig command. When installing multiple shared libraries, running
ldconfig once after all the files are installed is sufficient to
update the cache. Because of this, a package which needs this doesn't
run ldconfig directly from its postinstall script but 'triggers' a
ldconfig run instead. This means it informs the installation system
that ldconfig needs to be executed before this particular package will
be in a usable state. The installation system records this fact and
executes all actions triggered during installation of a series of
packages after all of them have been installed.
------------------------------
Date: Wed, 22 Aug 2012 22:30:43 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Two remarks about the Perl object model
Message-Id: <87haruehrw.fsf@sapphire.mobileactivedefense.com>
Negative one first: Destructors of superclasses aren't executed
automatically when an instance of a subclass with a destructor of its
own is destroyed. This implies that, in order to derive a class from
some other class, knowledge about the implementation of all ancestors
of the new class is required because a suitable order and mechanism to
cause superclass destructors to be executed needs to be worked out.
The positive one: A class is created by associating a reference to an
object of some type with a package. This is accomplished by calling
the bless-subroutine with suitable arguments. Because this is just an
ordinary runtime-operation, references which are already blessed into
a particular package can be 're-blessed' into a different package in
order to become an instance of a different class.
Example where this is useful: For a 'firewall-configuring application'
I need to manage sets of 'IP addresses' which are composed of objects
representing a single address and objects representing an address
range. An operation I need to perform on two such sets is to do an
ordered merge of them. This requires being able to merge any two
objects making up a continuous range into an equivalent, single range
object. If I can do destructive merging (usual case), this is
implemented by calling a method named change_addrs on the object
'containing' the new end-address of the combined range. If this
happens to be an object representing a single address, the method
transparently morphs that into a range object.
------------------------------
Date: Wed, 22 Aug 2012 21:25:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: undefine @array
Message-Id: <lrrfg9-r2b.ln1@anubis.morrow.me.uk>
Quoth Eli the Bearded <*@eli.users.panix.com>:
> does not use C<my> on the script level, uses C<use vars> instead
That's not necessarily a good idea. 'my' at the file level is scoped
over that file only; true globals are accessible throughout the entire
program, including other files. Unless you have a good reason for making
a variable globally accessible you should still be using 'my'.
Ben
------------------------------
Date: Wed, 22 Aug 2012 23:07:02 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: undefine @array
Message-Id: <6p1gg9-7bc.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> George Mpouras <nospam.gravitalsun@hotmail.com.nospam> wrote:
> > I expect a warning like "Global symbol "@array" requires explicit..."
> > but it did not compaint
>
> but later
> >yes I want to clear symbol @array completly but at the same scope
>
> These goals are not consistent. As Eli explained, that is not
> possible in Perl.
It is, actually, it's just not easy; also, it doesn't necessarily do
what you expect. The code to delete a global array looks like this:
# This assumes package main. BE CAREFUL playing with the symbol
# table directly: some versions of perl have bugs in this area which
# cause segfaults for no obvious reason, and it's entirely possible
# there are more bugs which haven't been found or fixed yet.
sub delary {
my ($sym) = @_;
no strict "refs";
my $old = \*$sym;
delete $::{$sym};
my $new = \*$sym;
*$old{$_} and *$new = *$old{$_}
for qw/SCALAR HASH CODE IO FORMAT/;
}
however, it's difficult to do anything useful with it. Calling it at
runtime:
use vars qw/@foo/;
@foo = 1;
say "Before delete: $foo[0] " . \@foo;
delary "foo";
say "After delete: $foo[0] " . \@foo;
use vars qw/@foo/;
@foo = 2;
say "After new: $foo[0] " . \@foo;
no strict "refs";
say "Symref: ${'foo'}[0] " . \@{"foo"};
gives this output:
Before delete: 1 ARRAY(0x83fb50)
After delete: 1 ARRAY(0x83fb50)
After new: 2 ARRAY(0x83fb50)
Use of uninitialized value in concatenation (.) or string at
/home/mauzo/src/perl/delary line 30.
Symref: ARRAY(0x81a308)
which shows that normal use of @foo continues to refer to the same
variable as before the deletion. This is because ordinary (non-symbolic)
variable references are resolved to a glob at compile time, so despite
the fact that *foo has been replaced with a glob which has no ARRAY
member, the compiled code still references the old glob and hence the
old @foo. The symref is not resolved until runtime, so that *does* see
the new array, but that won't get you 'strict' errors.
Performing the deletion at compile time is perhaps closer:
use vars qw/@foo/;
@foo = 1;
say "Before delete: $foo[0] " . \@foo;
BEGIN { delary "foo"; }
say "After delete: $foo[0] " . \@foo; # line 23
use vars qw/@foo/;
@foo = 2;
say "After new: $foo[0] " . \@foo;
no strict "refs";
say "Symref: ${'foo'}[0] " . \@{"foo"};
which gives a strict error (plus a warning you might not have expected):
Variable "@foo" is not imported at /home/mauzo/src/perl/delary line 23.
Variable "@foo" is not imported at /home/mauzo/src/perl/delary line 23.
Global symbol "@foo" requires explicit package name at
/home/mauzo/src/perl/delary line 23.
Global symbol "@foo" requires explicit package name at
/home/mauzo/src/perl/delary line 23.
BEGIN not safe after errors--compilation aborted at
/home/mauzo/src/perl/delary line 25.
and removing line 23 gives
Before delete: 1 ARRAY(0x83fb50)
After new: 2 ARRAY(0x83f838)
Symref: 2 ARRAY(0x83f838)
so the hard and symbolic refs are in sync again. However, since delary
has replaced the entire glob, any other symbols in the same glob will
also have been invalidated:
use vars qw/@foo %foo/;
@foo = 1; %foo = qw/foo bar/;
say "Before delete: $foo[0] $foo{foo} " . \@foo . \%foo;
BEGIN { delary "foo"; }
#say "After delete: $foo[0] " . \@foo;
use vars qw/@foo/;
@foo = 2;
say "After new: $foo[0] $foo{foo} " . \@foo . \%foo; # line 27
no strict "refs";
say "Symref: ${'foo'}[0] ${'foo'}{foo} " . \@{"foo"} . \%{"foo"};
Variable "%foo" is not imported at /home/mauzo/src/perl/delary line 27.
Variable "%foo" is not imported at /home/mauzo/src/perl/delary line 27.
Global symbol "%foo" requires explicit package name at
/home/mauzo/src/perl/delary line 27.
Global symbol "%foo" requires explicit package name at
/home/mauzo/src/perl/delary line 27.
BEGIN not safe after errors--compilation aborted at
/home/mauzo/src/perl/delary line 29.
and will need reimporting:
use vars qw/@foo %foo/;
@foo = 1; %foo = qw/foo bar/;
say "Before delete: $foo[0] $foo{foo} " . \@foo . \%foo;
BEGIN { delary "foo"; }
#say "After delete: $foo[0] " . \@foo;
use vars qw/@foo %foo/;
@foo = 2;
say "After new: $foo[0] $foo{foo} " . \@foo . \%foo; # line 27
no strict "refs";
say "Symref: ${'foo'}[0] ${'foo'}{foo} " . \@{"foo"} . \%{"foo"};
Before delete: 1 bar ARRAY(0x840420)HASH(0x840468)
After new: 2 bar ARRAY(0x82f720)HASH(0x840468)
Symref: 2 bar ARRAY(0x82f720)HASH(0x840468)
Notice that although the array has a different address, the hash has the
same address as before, and has kept its value.
> If you clear an array, like
> my @array;
> ...
> @array = ();
> or
> my @array;
> ...
> undef @array;
These are slightly different. '@array = ()' will empty the array, but
the storage allocated will be left allocated, on the assumption that you
will be filling the array up again later. This means that if @array had
500 elements before you emptied it, it will still have storage space for
500 elements after clearing.
'undef @array' will clear that storage, which is occasionally necessary
if for some reason you've allocated a huge array but you don't expect to
be doing so again. It's also worth noting that letting a lexical go out
of scope doesn't necessarily free all its storage: under some
circumstances perl will keep it around, again on the assumption that you
will be running this bit of code again soon and will need the allocation
again, so if that isn't true it can be useful to explicitly 'undef'
variables before they go out of scope.
The same applies to strings and '$foo = ""' vs 'undef $foo' vs letting a
scalar go out of scope.
Ben
------------------------------
Date: Wed, 22 Aug 2012 21:38:45 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using Template effectively
Message-Id: <XqWdnZe1koJZOKjNnZ2dnUVZ_tydnZ2d@supernews.com>
On 08/21/2012 09:13 AM, Ben Morrow wrote:
>
> Quoth Ben Morrow <ben@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
>
> perl
>
> as well. I was under the impression perl-base and perl were
> alternatives, but apparently you need both.
Thanks Ben. For my stage of the game, it clearly isn't a waste of my
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
$
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
------------------------------
Date: Wed, 22 Aug 2012 21:45:08 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using Template effectively
Message-Id: <4ZSdnRUL6pveOqjNnZ2dnUVZ_jKdnZ2d@supernews.com>
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
[sudo] password for fred:
Reading package lists... Done
Building dependency tree
Reading state information... Done
perl-modules is already the newest version.
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.
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
------------------------------
Date: Wed, 22 Aug 2012 21:57:42 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using Template effectively
Message-Id: <LoOdnftOd-arN6jNnZ2dnUVZ_uudnZ2d@supernews.com>
On 08/22/2012 09:45 PM, Cal Dershowitz wrote:
> 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
> [sudo] password for fred:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> perl-modules is already the newest version.
> 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.
> 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.
>
This is the only one that wasn't already the newest version:
$ 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:
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
------------------------------
Date: Wed, 22 Aug 2012 22:08:44 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using Template effectively
Message-Id: <J86dne7zFv5WMajNnZ2dnUVZ_qSdnZ2d@supernews.com>
On 08/21/2012 03:48 PM, Peter J. Holzer wrote:
> On 2012-08-21 20:56, Ben Morrow <ben@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
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
------------------------------
Date: Wed, 22 Aug 2012 22:26:12 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using Template effectively
Message-Id: <K42dnXCJat9_LajNnZ2dnUVZ_uSdnZ2d@supernews.com>
On 08/22/2012 01:49 AM, Mart van de Wege wrote:
> Ben Morrow <ben@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.
--
Cal
------------------------------
Date: Thu, 23 Aug 2012 10:09:55 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: using Template effectively
Message-Id: <slrnk3bpaj.bov.hjp-usenet2@hrunkner.hjp.at>
On 2012-08-23 04:08, Cal Dershowitz <cal@example.invalid> wrote:
> On 08/21/2012 03:48 PM, Peter J. Holzer wrote:
>> On 2012-08-21 20:56, Ben Morrow <ben@morrow.me.uk> wrote:
>>> 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
> 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,
This thread has moved to a slightly different topic, but the error
message you quoted was:
| You need to install the perl-doc package to use this program.
So you just had to run
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.
I have no idea what you mean by "perl the module".
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Thu, 23 Aug 2012 10:30:07 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: using Template effectively
Message-Id: <87628a3qhs.fsf@sapphire.mobileactivedefense.com>
Cal Dershowitz <cal@example.invalid> writes:
> 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.
[rw@sapphire]~ $perl -e 'use NoSuchModule;'
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.
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3765
***************************************
