So it would seem my PEAR binaries should be in the path (at the very end).
But when I try and run the PEAR binary from the command line, I get the following:
pavilion:~ # pear version
-bash: pear: command not found
pavilion:~ #
But if I try running from the command line with the full path, I get the following:
pavilion:~ # /usr/share/php5/bin/pear version
PEAR Version: 1.9.0
PHP Version: 5.2.6
Zend Engine Version: 2.2.0
Running on: Linux pavilion 2.6.18.8-0.9-default #1 SMP Sun Feb 10 22:48:05 UTC 2008 i686
pavilion:~ #
So what’s going on?.. The folder containing the PEAR binary seems to be in $PATH but I cannot run the binary without prepending the path.
I’m not sure either option makes a difference. I assume by ‘useless’ you
mean because PATH is already exported. Moving the way it is set seems
useless because we already know it is set but still the executable is not
found. Setting it somewhere else will not make a difference unless there
is a serious bug somewhere (doubtful).
Good luck.
On 02/21/2010 02:56 AM, hcvv wrote:
>
> That’s correct, but the -export PATH- is useless.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Thanks but I would like to add it to the path for all users. Also, I liked to know why I cannot execute the binary when its directory does appear in the $PATH echo.
Thanks but can you please clarify that… I was just copying syntax I saw posted elsewhere.
Does the Export PATH do nothing… Or is it just unnecessary given the earlier line of code?
What is the correct code snippet for appending or prepending to the PATH?
Also, why doesn’t the binary execute even though its directory does appear in the PATH?
From looking at other threads and forums, it appears that SUSE (and other distro’s)have a multitude of directories where one can add a script file for appending or prepending to the path. I used /etc/profile.d but is that the correct directory? Also, what is the effect of the shell script extension. I used pear.sh but I noticed other shell scripts with .tcsh, .csh, .bash. I understand there are several different shells, does each shell have its own $PATH variable. My “command not found” appears with --bash in front of it. Should I have named my script pear.bash instead of pear.sh?
Sorry, I must be a bit more clear about my post. I only acted on the
PATH=$PATH:/usr/share/php5/bin/
export PATH
sequence because I see that often and nobody who gives it seems to care about what it means.
You can work with variables in bash (as in most shells), but there existence is restricted to the shell process that they are defined and used in. When you want to have variables in the process environment to be available in newly forked processes, you can export such a variable and its value to the environment with the export statement.
But as PATH is already inherited from the parent process (else there would be nothing in it) there is no need to export it again. You only need to change its value.
Back to your problem.
I think there is no need to do a
PATH=$PATH:/usr/share/php5/bin/
because your echo $PATH proves that it is already there. We must concentrate on why the program is still not found.
Did you try a
which pear
And, why we are searching for something we do not quite understand, some silly questions as what is the output of
According to ‘which’ there is no ‘pear’ in the path (in spite of appearances… :\ ). See:
pavilion:~ # which pear
pavilion:~ #
ls -l of the directory results in:
pavilion:~ # ls -l /usr/share/php5/bin/
total 12
-rwxr-xr-x 1 root root 793 Feb 20 19:46 pear
-rwxr-xr-x 1 root root 814 Feb 20 19:46 peardev
-rwxr-xr-x 1 root root 730 Feb 20 19:46 pecl
pavilion:~ #
I would be quite happy to put the PEAR and bin directories somewhere else.
I downloaded a PHP script (go-pear.php) from the PEAR site and ran ‘php go-pear.php’. The script then created and populated the bin and a PEAR directories in the local directory.
If /usr/share/php5/ isn’t the correct location, what is?
In fact, it would not be inherited from a parent process, it must be changed in the current shell, because the effect of a variable change can only affect child processes, not the parent process.
If you look at how the files in /etc/profile.d are dealt with, they are sourced (.), not run as subshells.
But this is incidental to finding out why pear is not found.
boven:~ # which pear
which: no pear in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin)
boven:~ #
I did not say the place was not correct, but strange. Mostly these go to /usr/bin or /usr/local/bin or in /opt/… But ideas differ and maybe one should know the product better then I do to make a statement. It should function from almost any place. And if this install puts it there, moving can give problems when other parts of the product think it is were it was.
Another test could be: put a small script in that directory (do not forget to make it executable), let us say the name is path-test and the contents:
#!/bin/bash
# Test if the PATH to this works
echo "Test of the PATH, the PATH is: ${PATH}
echo "And the call was ${0} ${*}
and call that instead of pear.
EDIT: @ken_yap, Good idea, I always forget that one, but as you say it would be an unusual partitioning.
To be honest, I don’t know what these commands do but here you go:
pavilion:~ # df /usr/share/php5/bin
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 20641788 4182768 15410380 22% /
pavilion:~ # mount
/dev/hda5 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda6 on /home type ext3 (rw,acl,user_xattr)
securityfs on /sys/kernel/security type securityfs (rw)
pavilion:~ #
echo "Test of the PATH, the PATH is: ${PATH}
echo "And the call was ${0} ${*}
pavilion:/usr/share/php5/bin # path-test
-bash: path-test: command not found
pavilion:/usr/share/php5/bin # pear
-bash: pear: command not found
pavilion:/usr/share/php5/bin # /usr/share/php5/bin/path-test
-bash: /usr/share/php5/bin/path-test: /bin/bash^M: bad interpreter: No such file or directory
pavilion:/usr/share/php5/bin # ls -l path-test
-rwxr-xr-x 1 root root 125 Feb 22 18:44 path-test
pavilion:/usr/share/php5/bin # /usr/share/php5/bin/pear
Commands:
build Build an Extension From C Source
bundle Unpacks a Pecl Package
channel-add Add a Channel
channel-alias Specify an alias to a channel name
channel-delete Remove a Channel From the List
channel-discover Initialize a Channel from its server
channel-info Retrieve Information on a Channel
channel-login Connects and authenticates to remote channel server
channel-logout Logs out from the remote channel server
channel-update Update an Existing Channel
clear-cache Clear Web Services Cache
config-create Create a Default configuration file
config-get Show One Setting
config-help Show Information About Setting
config-set Change Setting
config-show Show All Settings
convert Convert a package.xml 1.0 to package.xml 2.0 format
cvsdiff Run a “cvs diff” for all files in a package
cvstag Set CVS Release Tag
download Download Package
download-all Downloads each available package from the default channel
info Display information about a package
install Install Package
list List Installed Packages In The Default Channel
list-all List All Packages
list-categories List All Categories
list-category List All Packages of a Category
list-channels List Available Channels
list-files List Files In Installed Package
list-packages List All Packages of a Channel
list-upgrades List Available Upgrades
login Connects and authenticates to remote server [Deprecated in favor of channel-login]
logout Logs out from the remote server [Deprecated in favor of channel-logout]
makerpm Builds an RPM spec file from a PEAR package
package Build Package
package-dependencies Show package dependencies
package-validate Validate Package Consistency
pickle Build PECL Package
remote-info Information About Remote Packages
remote-list List Remote Packages
run-scripts Run Post-Install Scripts bundled with a package
run-tests Run Regression Tests
search Search remote package database
shell-test Shell Script Test
sign Sign a package distribution file
svntag Set SVN Release Tag
uninstall Un-install Package
update-channels Update the Channel List
upgrade Upgrade Package
upgrade-all Upgrade All Packages [Deprecated in favor of calling upgrade with no parameters]
Usage: pear [options] command [command-options] <parameters>
Type “pear help options” to list all options.
Type “pear help shortcuts” to list all command shortcuts.
Type “pear help <command>” to get the help for the specified command.
pavilion:/usr/share/php5/bin #
The odd thing is that the full ‘/usr/share/php5/bin/path-test’ fails while ‘/usr/share/php5/bin/pear’ does successfully execute the pear binary.
Yes, this will make a mess out of everything we try. First get rid of all those Cariage Returns. And find out how you got them there to avoid doing this again.
And do this also in all the scripts and/or text that has anytrhing to do with your problem (like the PATH=$PATH statement)!