I'm adding some comments between yours. To me the state of affairs reminds me
of the terrible problems I got into when first moving from MacPerl on OS 9 to
"real" perl on OS 10. With Fink, DarwinPorts, and CPAN I got really lost.
Darwin is now MacPorts and CPAN has been improved but I'm stuck on OS 10.3.9
because I insist on using my SE/30 file server from long ago. Ubuntu is fun.
What I have been personally doing is just not using stuff directly from any of
those "we'll do it for you" schemes that seem always to have an entirely
different idea about how I want to organize my life with my computer. I use
those sites as sources of code but I pretty much always recompile the stuff
here or, in the case of perl modules that don't use any included C code, it's
just a copy of the source. I put things in my home directory under $HOME/perl/
and point to that with $PERL5LIB. It's often a pain because of dependencies
that you don't discover right away but I prefer that to not having the foggiest
idea where things were put.
You are less familiar with command line UNIX than I am and I am still having
problems because of my prior experience on a 64 kiloword UNIX box in the late
1970's gets in the way of more modern tools. I'm also a csh user who has never
figured out sh and bash.
Others on this list are more knowledgeable than I. I hope some of them will
have suggestions based on comments here and below.
At 22:23 +0100 9/17/09, Mine wrote:
>You are right the first line of get_iplayer is #!/usr/bin/perl
That's pretty much standard these days. It's there so the UNIX kernel knows
what software - perl - to use when executing a file by typing its name at the
start of a command line.
>Up to line 25 appear like comments about the program.
>Line 26 is: package main;
>Line 50: use Env q...@path];
Normally the environment variable PATH would be accessed by $p = $ENV{'PATH'};
followed by a split command to change the string to a list of individual
directories. This author uses the Env module probably because perl works in
non-UNIX environments and the module makes the code portable.
>Line 51 down to 69 is the Perl modules to use
>use Env q...@path];
>use Fcntl;
>use File::Copy;
>use File::Path;
>use File::stat;
>use Getopt::Long;
>use HTML::Entities;
>use HTTP::Cookies;
>use HTTP::Headers;
>use IO::Seekable;
>use IO::Socket;
>use LWP::ConnCache;
>#use LWP::Debug qw(+);
>use LWP::UserAgent;
>use POSIX qw(mkfifo);
>use strict;
>#use warnings;
>use Time::Local;
>use URI;
>use POSIX qw(:termios_h);
Those seem reasonable. Note that the # lines are commented out. They were
likely used during debugging by the author.
>When I use either of the following:
>> /usr/local/bin/perl -w get_iplayer
>> /usr/local/bin/perl5.10.1 -w get_iplayer
With all of the copies of perl you seem to have the execute line with the
complete path to perl5.10.1 is probably what you should be sticking with..
With it you will be ignoring the #! line in the code for get_iplayer. You
might also want to prepare a complete path for get_iplayer and put it into the
command. Your shell will allow you to make an alias of the line so it's easy to
repeat.
>
>
>I get this in the Terminal:
>Can't locate loadable object for module HTML::Parser in @INC
(@INC contains:
/usr/local/lib/perl5/5.10.1/darwin-2level
/usr/local/lib/ perl5/5.10.1
/usr/local/lib/perl5/site_perl/5.10.1/darwin-2level
/usr/local/lib/perl5/site_perl/5.10.1 .)
at /usr/local/lib/perl5/5.10.1/ HTML/Entities.pm line 145
>Compilation failed in require at /usr/local/lib/perl5/5.10.1/HTML/ Entities.pm
>line 145.
>Compilation failed in require at get_iplayer line 56.
>I assumed that some of the modules are missing so when I used to try and
>install then I get the following:
>cpan> install HTML::Entities
>HTML::Entities is up to date.
What's happening is that HTML::Entities contains a "use HTML::Parser" probably
at line 145. I would look up the code for HTML::Entities and have a look. With
luck the module will be pure perl with no C-language parts. In any case what
you would need to install is HTML::Parser - and anything it uses. The problem
is recursive dependencies which CPAN, and the other port services are supposed
to be taking care of. My experience with that is terrible and, by the way, it's
not so good in many UNIX distributions other than OS neXt either.
>
>CPAN seems to think all the modules are up to date.
>
>> Do a Finder "get info" on /usr/bin/perl and post what it says.
>
>No sure what you need me to post. Kind: Unix Executable File, Size: 20 KB,
>Where: /usr/bin, Open with: not applicable.
Yeah. Finder doesn't speak perl or UNIX very well.
>
>> ls -lF /usr/bin/perl*
>
>-rwxr-xr-x 1 root wheel 19280 Jan 30 2006 /usr/bin/perl*
>-rwxr-xr-x 1 root wheel 19280 Jan 30 2006 /usr/bin/perl5.8.6*
That pair is interesting. It would be common to have /usr/bin/perl be a hard
link (man ln for more about that) to the version of perl that a user wants to
use. It might be created this way
ln /usr/bin/perl5.8.6 /usr/bin/perl
or
ln /usr/local/bin/perl5.10.1 /usr/bin/perl
which would give you the choice of what that #! line would decode to.
The 1 before "root" in the ls listing is the number of links to each file. If
/usr/bin/perl were a link to /usr/bin/perl5.8.6 both of those lines would have
2 instead of 1. That indicates that in /usr/bin you really have two copies of
perl. The fact that they are both exactly the same length makes me wonder about
the way Apple does things.
>-rwxr-xr-x 1 root wheel 37615 Jan 12 2009 /usr/bin/perlbug*
>-rwxr-xr-x 1 root wheel 17953 Jan 30 2006 /usr/bin/perlcc*
>-rwxr-xr-x 1 root wheel 224 Jan 30 2006 /usr/bin/perldoc*
>-rwxr-xr-x 1 root wheel 11667 Jan 30 2006 /usr/bin/perlivp*
Those are reasonable except that I donno what perlivp does.. perldoc is an
executable you can use to read in-line documentation for perl modules and
scripts.
> file /usr/bin/perl
>/usr/bin/perl: Mach-O executable ppc
That's what I would hope Finder would say with a get-info. Sigh.
>No sure if this is useful, but MacPorts has created a .profile with the
>following:
>test -r /sw/bin/init.sh && . /sw/bin/init.sh
It sure seems weird.
>##
># Your previous /Users/terrenceward/.profile file was backed up as /
>Users/terrenceward/.profile.macports-saved_2008-09-21_at_03:26:23
>##
># MacPorts Installer addition on 2008-09-21_at_03:26:23: adding an
>appropriate PATH variable for use with MacPorts.
>export PATH=/opt/local/bin:/opt/local/sbin:$PATH
># Finished adapting your PATH environment variable for use with MacPorts.
That is obscene!! It's an example of what ought not to be done! They politely
save a copy of your original startup file of bash and sh and then change your
$PATH apparently so it will get changed every time you start up a shell. That
makes it a bit silly to go through a process of setting PATH so it works by
even having an environment.plist file. Shells have startup files in your home
directory and also in /etc/. Some get executed whenever you start a new shell
and others are executed in when you log in. But remember logging in to a shell
is NOT the same as logging in to OS neXt!
And, if you're like me - devoted to tcsh, that polite change was not
accomplished. The startup files for csh are different.
># MacPorts Installer addition on 2008-09-21_at_03:26:23: adding an
>appropriate MANPATH variable for use with MacPorts.
>export MANPATH=/opt/local/share/man:$MANPATH
># Finished adapting your MANPATH environment variable for use with MacPorts.
>
>
># MacPorts Installer addition on 2008-09-21_at_03:26:23: adding an
>appropriate DISPLAY variable for use with MacPorts.
>export DISPLAY=:0
># Finished adapting your DISPLAY environment variable for use with MacPorts.
And messing with the DISPLAY variable is a really good way to make X-11 fail
while trying to log in to a Linux box from your Mac.
>Perl -v returns
>This is perl, v5.8.8 built for darwin-2level
Assuming you really typed perl, UNIX is pretty much case sensitive, that
indicates that the system found perl not in /usr/bin/ but rather in
/opt/local/bin because MacPorts politely added it to the start of your PATH
without permission. I'll bet there is a link. /opt/local/bin/perl that points
to /opt/local/bin/perl5.8.8. ls -lF /opt/local/bin/perl* might be informative.
>
>I also opened the environment.plist:
>open ~/.MacOSX/environment.plist
>a property list editor open and showed:
>/usr/local/bin:/usr/local/lib:/opt/local/bin:/opt/local/sbin:/usr/
>bin:/bin:/sbin:/usr/sbin
Yeah. And when you started bash, by opening a terminal session, that modified
.profile file changed PATH for you.
In short. . . It looks as though your problems would go away if you made
extensive use of full pathnames for the perl's you want to use. Set up
environment variables or shell aliases for them so you don't have to retype all
the time. Create a $HOME/.bashrc file that will set things up automatically
every time you start a new shell be it a new terminal window or something from
within a terminal window that uses a new shell process. Something I have done
is to put some echo statements in my shell startup file that print things like
$PATH to a log file. It's a way to find out what other folks are doing behind
your back.
And you'll need that HTML::Parser module. It might well be in Apple's perl
installation in a usable form. There is probably a way to make OS 10 find it
for you. The UNIX tool find (man find) does things like that but creating the
command line with its quotes and -print options will be a challenge. Personally
when I find things like that I copy them into my private PERL5LIB so they don't
get lost.
Please keep up posted. I'm sure you will get there.
I'm off to figure out what get_iplayer does. For a while I thought it was
something like mplayer which is a competitor for quicktime.
--
Applescript syntax is like English spelling:
Roughly, though not thoroughly, thought through.
