-2

I've just finished compiling PHP and wanted to take it for a test drive but php index.php is not working, however, ./php index.php does work.

For what it's worth I am able to do httpd -t with no problem from Apache's httpd/bin directory.

# pwd
/usr/local/php/x64/7.2.2/bin

# ls -la
total 100620
drwxr-xr-x. 2 root root      163 Feb 19 12:58 .
drwxr-xr-x. 8 root root       76 Feb 19 12:52 ..
-rw-r--r--. 1 root root       19 Feb 19 12:58 index.php
-rwxr-xr-x. 1 root root      887 Feb 19 12:52 pear
-rwxr-xr-x. 1 root root      908 Feb 19 12:52 peardev
-rwxr-xr-x. 1 root root      824 Feb 19 12:52 pecl
lrwxrwxrwx. 1 root root        9 Feb 19 12:52 phar -> phar.phar
-rwxr-xr-x. 1 root root    53504 Feb 19 12:52 phar.phar
-rwxr-xr-x. 1 root root 34058464 Feb 19 12:52 php
-rwxr-xr-x. 1 root root 33900816 Feb 19 12:52 php-cgi
-rwxr-xr-x. 1 root root     2309 Feb 19 12:52 php-config
-rwxr-xr-x. 1 root root 34980264 Feb 19 12:52 phpdbg
-rwxr-xr-x. 1 root root     4593 Feb 19 12:52 phpize

# php index.php
-bash: php: command not found

# ./php index.php
hi

# /usr/local/php/x64/7.2.2/bin/php index.php
hi

Is there something that I am missing? If I could just be pointed to a question which answers something similar then that would be a huge help. As of now, I don't even know how to Google this issue properly.

If it matters I am using SSH from my Windows host to my VirtualBoxed CentOS 7.

MonkeyZeus
  • 143
  • 1
  • 8
  • I doubt that `/usr/local/php/x64/7.2.2/bin` is in your `$PATH`. If you want to run this version of `php` without giving the full path to the executable, include it in your `$PATH` via modifying the path, or linking the executables to a directory which _is_ in your `$PATH`. – user4556274 Feb 19 '18 at 19:29
  • @user4556274 So even though my `pwd` reports `/usr/local/php/x64/7.2.2/bin`, I cannot directly access `php` without having it in one of my path folders? – MonkeyZeus Feb 19 '18 at 19:31
  • By default (for security), the current working directory `.` is not in your `$PATH`. As you observe, you can explicitly call the executable by the relative path `./php`, or you can add `.` to your `$PATH` to always be able to execute binaries in your current directory. (Possible, not good practice.) – user4556274 Feb 19 '18 at 19:36
  • @user4556274 I see. I added a symlink named `php72` into `/usr/local/bin` and it seems to be working as expected now. Sorry for the newb question(s), the learning curve is a little steep at the moment but hopefully I'll git good one day. Thank you. – MonkeyZeus Feb 19 '18 at 19:48

2 Answers2

4

If the binary is not in one of the directories listed in your PATH variable, then you will not be able to execute it without specifying the path to it (a relative or absolute path).

Since you specified ./ (the current directory), and since the executable happened to be available in the current directory, the shell knew where to find it.

The correct way to solve your issue if you want to use php and the other executables in the same directory, without always having to specify the path, is to add /usr/local/php/x64/7.2.2/bin to the value of PATH in your ~/.bashrc file:

PATH="$PATH:/usr/local/php/x64/7.2.2/bin"

The new path will be active in all new shells.

This way you don't have to sudo to root to add symbolic links anywhere that may confuse future software installations on your machine.

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
  • Thanks for putting up this answer. This explains a lot. I decided to just add a symlink into `/usr/local/bin` because it seems most proper per [FHS](http://www.pathname.com/fhs/), and I do not want to muck up my paths beyond all recognition. – MonkeyZeus Feb 19 '18 at 20:18
  • @MonkeyZeus The only issue with the symbolic link solution (which is perfectly valid) is that you're bound to forget about it and will end up with a dangling symlink at some point. This may or may not be an issue for you. By changing `PATH`, you make a change that you could even possibly document with a comment in the file, and there's no need to muck about in the filesystem any further. – Kusalananda Feb 19 '18 at 20:22
  • I see, would this mean that every user would also need this added to `$PATH`? Is there a more global way of achieving this convenience? – MonkeyZeus Feb 19 '18 at 20:30
  • @MonkeyZeus I believe that this question may be answered here: https://unix.stackexchange.com/questions/104727/add-a-path-in-path-globally-for-every-user – Kusalananda Feb 19 '18 at 20:39
  • I've ultimately decided that symlink is going to work best for me. I will be running PHP7 and PHP5 on the same system due to a huge code base relying on `mysql_*` extension. This way I can use `php56` or `php72` in the shell as needed. Online, I have seen a great deal of confusion caused by people simply having no clue where their PHP installation resides and why `php -v` shows "wrong" information after an upgrade. Also, in regards to my install path, should I be compiling it into something like `/opt/programs/x64/php/7.2.2` instead? And use `/opt/bin` for the symlink and add it to `$PATH`? – MonkeyZeus Feb 20 '18 at 12:51
  • @MonkeyZeus That is entirely up to you and what you think is the most convenient. – Kusalananda Feb 20 '18 at 13:17
1

When you write

php /path/to/somefile.php

then bash(Linux default shell) first searches for php in paths specified in global variable $PATH. When you create symbolic link for php in /usr/local/bin then that is working because /usr/local/bin by default present in $PATH in most of Linux flavors. You can check it by:

echo $PATH

It should come like:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

Same thing you are achieving when you are providing /usr/local/php/x64/7.2.2/bin in $PATH other way round.

When you write

./php /path/to/somefile.php

or

/usr/local/php/x64/7.2.2/bin/php /path/to/somefile.php

bash interpret that you are providing path to php file manually and don't search for it in $PATH. Rather it searches for php file in path you specified.

YATIN GUPTA
  • 111
  • 1