Hi Doug,
Thanks for your help. After reinstalling some modules with MacPorts,
I can now get
get_iplayer to work with /opt/local/bin/perl5.8.8 -w get_iplayer.
I don't use this method I get the missing HTML entities error.
The only thing I need to figure out now is how to get flvstreamer to
work. I believe I
need this to be able to download HD programs. It says it is a unified
binary which
I have not come across before, so I am trying to figure out how to
install it.
I would be most interested in knowing what you find out about
get_iplayer.
Thanks,
Terrence
On 21 Sep 2009, at 17:11, Doug McNutt wrote:
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.
