problems with using "pear install"

help and advice needed

[adwhite]

Hi,

I've just installed pear (and the package manager) on my server, everything went fine and pear changed the php.ini to point to the correct repository for the pear packages.

But when I run "pear install HTML_Common" from the command line I get :-

/usr/bin/pear: /usr/local/bin/php: No such file or directory

which is correct because php is in /usr/bin/php (which I correctly configured for the install)

Does anyone now how to correct the path that pear is using?

Thanks

Andy

[mcibor]

I haven't tried to do that, but why don't you search the disk for * with containing text "/usr/local/bin/php" Especially search in /etc

Hope that helps

Michal Cibor

[adwhite]

This is on a unix machine, can I do that on a unix?

[jezra]

adwhite, yes you can do the search. In fact it can be done with PHP, sort of. You will want to run the following as ROOT.

<?
//print the names of files containing a specified string
function find_in_folder($folder,$string)
{
 global $noMatchFound;
 $folderHandle = opendir($folder);
 if($folderHandle)
 {
 while ( ($folderAsset = readdir($folderHandle) )!== false)
 {
 if ( $folderAsset!=".." && $folderAsset!="." )
 {
 $assetPath = "$folder/$folderAsset";
 if(is_dir($assetPath) &&!is_link($assetPath) )
 {
 find_in_folder($assetPath,$string);
 }elseif(!is_link($assetPath) ){
 $fileText = file_get_contents($assetPath);
 if( strstr($fileText,$string) )
 {
 echo "$assetPath\n";
 $noMatchFound=false;
 } 
 }
 }
 }
 closedir($folderHandle);
 }
}
$noMatchFound=true;
//change the following variables as needed
$startFolder = "/etc";
$searchString = "usr/local/bin/php";
find_in_folder($startFolder,$searchString);
if($noMatchFound)
{
 echo "No match was found\n";
}
?>

[mcibor]

Or just use mc (Midnight Commander). I don't know the exact command, but in my version it's in menu between FILE and OPTION (I don't know the english version name, it's sth like command) then FIND FILE. There you have three inputs: path (/ - for root dir or /etc/); file (I would put * - for everything), contains (here the desired text).

Best regards!
Michal Cibor

PS. Thanks jezra for the interesting code!

[adwhite]

Hi,

Because PEAR is properly installed I've got round the problem with the package manager by downloading the appropriate packages directly from pear and then manually installing them in the correct pear sub-directory.

This all seems to be working fine, but if anyone knows why I shouldn't be doing this please let me know.

[mcibor]

No. if it's working fine it's a better way! The way I suggested is a bit around the problem really, it's not a proper way to do, however it may work:)

I just kind of corrected my mc with that. I couldn't write polish letters under Mandrake 10.1, but I could under Aurox. So I copied some ini and conf files from the Aurox version into the Mandrakes, as well as the program file (mc). Certainly there was some problem with libraries, so I copied the program file back to the original version of Mandrake. You can imagine my surprise when I found that polish letters are working now! l -> ³, etc. :)

So as you see, your way is much better!

Best wishes!
Michal Cibor

[jatar_k]

bump for coop ;)

[coopster]

Thanks, jk for opening this backup. Kind of nice having an admin around these parts ;-)

Because pear is properly installed I've got round the problem with the package manager by downloading the appropriate packages directly from pear and then manually installing them in the correct pear sub-directory.

This all seems to be working fine, but if anyone knows why I shouldn't be doing this please let me know.

I ran into this problem recently on a RHES installation. Could not figure out for the life of me why everything is in place but the pear command wouldn't run anything. It would run, but no errors, no listings, no installs, no nothing would occur. I mean, if I keyed in "pear remote-list" the command would run but would return nothing. Just straight back to the bash prompt.

Well, I peeled open the bash script and started running the command using the command line switches shown in the *exec* line of the script. It came down to eliminating the INCARG parm from the command:

#exec $PHP -C -q $INCARG -d output_buffering=1 $INCDIR/pearcmd.php "$@" 
exec $PHP -C -q -d output_buffering=1 $INCDIR/pearcmd.php "$@"

Now all works fine. However, anyone care to tell me why? ;)

[MattyMoose]

Hey coop, I'm looking at what you've written, and I have finally found out what all the switches mean! What I'd like to know is what INCARG is actually evaluating to...

can you do a

grep 'INCARG'

on that script for me, tell me what it's setting it to? Then maybe do an

echo $INCARG

right before that line you posted? I'm now curious... :)

Matt

[jatar_k]

me too ;)

our reference for this by the way was here
[php.net...]

[coopster]

Sorry about that, I could have told you what the switches meant, I had to dig deep to find them as the php command itself does not reflect the *full* switch definitions, I had to dig to find some of them in the pearcmd.php script, which never gets echoed to the screen by the looks of it!

Echo them out? Oh yeah, no problem. I echoed the values out for myself to see what they were when I was troubleshooting this animal. INCARG is being set to the very last value in the if/else structure which in this installation happens to be:

/usr/local/lib/php

... and that is indeed where the pear stuff is located (php is a directory). I tried creating a directory in that sub directory named *pear* and copied all the PEAR stuff into that subdirectory recursively just to see if pear "required" it to be as such to no avail, still made no difference, not until I modified that exec command to eliminate the argument specified, INCARG.

[jatar_k]

little wonder it doesn't work then, that should be the value of $PHP but I was figurin $INCARG would be some extra switches or something.

I guess it is just crap then and that is why it doesn't work ;)

[coopster]

Thanks for the heads up on the manual pages there, btw. I didn't even think of going there, duh.

The value of $PHP is the path to the binary

/usr/local/bin/php

... and I told you incorrectly, sorry about that. I gave you the INCDIR var. Here are all three variables in that pear script when I echo them to STDOUT:

PHP = /usr/local/bin/php 
INCDIR = /usr/local/lib/php 
INCARG = -d include_path=/usr/local/lib/php

Thanks for correcting me there, jk.

[jatar_k]

that's why then, it's still crap

it would look like this

exec /usr/local/bin/php -C -q -d include_path=/usr/local/lib/php -d output_buffering=1 /usr/local/lib/php/pearcmd.php "$@"

and 2 -d's won't work methinks, though this might

exec /usr/local/bin/php -C -q -d include_path=/usr/local/lib/php output_buffering=1 /usr/local/lib/php/pearcmd.php "$@"

<added>actually looking at that this might even work

exec /usr/local/bin/php -C -q -d include_path=/usr/local/lib/php output_buffering=1 pearcmd.php "$@"

[coopster]

Nope, that didn't work. pear must require a -d switch for each directive override by the looks of it...

Could not open input file: output_buffering=1

Good thought though. We'll give you one point for a good idea on that one ;)

[jatar_k]

repeating switches, that can't be right, maybe a semi colon (or some other) seperator?

can you believe I can't find one reference to using multiple config overrides with php cli in anything that comes up with tons of different searches.

[coopster]

Not entirely sure about the internals but the dual switch works on a Windows setup ...

php -C -q -d include_path=c:\php -d output_buffering=1 c:\php\pear\pearcmd.php remote-list

... returned the list, just as expected. Go figure. First time I've ran into that, something that worked on Win but not *nix ;)

[jatar_k]

that just means it doesn't work at all ;)