Re: Help setting Perl path

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 qw[@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 qw[@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.