bradgrafelman has been a huge help in getting me this far, but I've still got a missing link between creating a script that runs correctly in the ksh shell and using that script in a cron job.

This works perfectly in the shell:
$ php -c /usr/local/opt/coolstack/php5/lib -f __laagjob.php
...this php script runs without a hitch and does what I need it to do (run some mysql actions like replacing a table).

I also now know how to create a crontag, and it appears to run at the correct time. ie:
* ./shebang.php (this runs every minute while I'm testing this)

THE PROBLEM IS THIS: The job runs, but it does not find php and so the cron job sends me a message that the script ran but did not do what it's supposed to do...even with a simple HELLO WORLD action.

Here is the "shebang.php" script. Note that the shebang line contains the same path that DOES work in the shell commad that I said works perfectly.

#!/usr/local/opt/coolstack/php5/lib
<?php
echo "HELLO WORLD\n";
?>

The message that I get back from the server is:
Your "cron" job on www.blah.blah
./shebang.php
produced the following output:
sh: ./shebang.php: not found

I have found that in the shell, the following DOES appear to work:

$ php ./shebang.php
HELLO WORLD

However, if I try to add the php into the crontab line, the message still comes back like this:
Your "cron" job on www.blah.blah
php ./shebang.php
produced the following output:
sh: php: not found

I feel like I'm really close here. I guess it must have something to do with the syntax of the shebang line (#!/usr/local/opt/coolstack/php5/lib) in the php script.

    You still don't understand how the shebang line works.

    What that line should look like is this:

    #!<path-to-executable> <arguments-for-that-executable>

    In other words, the path directly following "#!" should be to a binary file you could actually execute from the shell/prompt.

    You can Google for examples of a proper shebang line with arguments, but here's one example from Wikipedia:

    #!/usr/bin/env python -c

      A shebang in a PHP script is only necessary if you want to run that script without having to type the path/to/php bit:

      nix_prompt$ ./file_with_shebang.php

      NOTE that file_with_shebang.php must have executable permissions for whatever user is trying to type that command.

      You can still run a php file with no shebang if you are willing to type the path to php:

      nix_prompt$ /usr/bin/php no_haz_shebang.php

      In that case, no_haz_shebang.php does not need to be executable.

      I think the problem here is that you are typing a relative path when you try to create your crontab. This may work when you type it in a terminal:

      nix_prompt$ ./shebang.php

      But that is because shebang.php exists in the current working directory.

      When a crontab runs, the current working directory could be anything. Actually that's not true...I think there is some predictable current working directory for cron jobs. However, whenever you write a crontab entry, you should never make assumptions about the current working directory. You'll want to type the entire absolute path to your script. It's also helpful to route the output of any crontab entry to some file so you can check it later.

      Maybe try something like this:

      * * * * * /full/path/to/shebang.php > /full/path/to/some/text/file.txt

      Obviously you should replace the file paths with the correct real file paths of two real files. NOTE the leading slash. This means you are specifying the full absolute path of these files relative to the root of your file system.

        Also note that there's probably no need to worry about using the shebang line at all, as I don't see why you couldn't use "php -c /path/to/lib-folder/ /ABSOLUTE/path/to/your/script.php" as the cronjob command.

          No, clearly after two solid days of plugging away at this I clearly don't. I've gotten into programming kind of sideways and I lack a lot of basic context, particularly when using the shell/PuTTY. I guess the thing I am currently confused about is the term "executable". Is it the php language that I am trying to connect to or the script I am trying to run?

          when I create a new file called "grr.php" like so:
          (the shebang contains the path to php, according to your python example I substituted "php" for python and added the -c) so I am thinking the php and the -c are the arguments?

          So, following your model:
          #!<path-to-executable> <arguments-for-that-executable> I start my .php file (outside the php tags with this shebang
          #!/usr/local/opt/coolstack/php5/lib php -c

          filename grr.php

          #!/usr/local/opt/coolstack/php5/lib php -c
<?php
// REPLACE LAAGCOMP TABLE
$link=mysqli_connect("localhost",  "me", "pass", "probsolve")  or die("Could not connect : " . mysql_error());
$part4="INSERT INTO CRONRUNS (JOB) values ('laagjob')";
mysqli_query($link,$part4); echo "part4: record in CRONRUNS<br>\n";
?>

          If the CONCEPT of the shebang above is correct, then the only other thing I can think is that there is some wrong selection of subdirectories in the path to php

          here is what happens when I try to run exactly this file (with the proper credentials in the connect section) in the shell

          $ grr.php
          ksh: grr.php: not found

          $ ./grr.php
          ksh: ./grr.php: cannot execute

          $ php ./grr.php
          Fatal error: Call to undefined function mysqli_connect() in /usr/local/www/htdocs/psi/grr.php on line 3

            For one, read my comment above - you probably don't even need to use a shebang line at all.

            But again, going back to my explanation:

            #!<path-to-executable>

            you have this:

            #!/usr/local/opt/coolstack/php5/lib

            So you're saying that in the folder /usr/local/opt/coolstack/php5/, there is an executable binary named 'lib'?

              When you login using SSH/puTTY, the linux system speaks to you with a shell program. In your case, it looks like k-shell (ksh).

              The shell is responsible for interpreting your commands. I use bourne again shell (bash).

              Both shells have the concept of current working directory. The current working directory is sort of analogous to whatever folder you happen to be starting at in windows explorer or the file manager on a mac. You can see what your current working directory is at any time by typing 'pwd' and hitting enter.

              Mac:~ sneakyimp$ pwd
/Users/sneakyimp

              This tells me my current working directory is /Users/sneakyimp. I can change this directory using the cd command.

              Mac:~ sneakyimp$ cd /applications/mamp/htdocs/
Mac:htdocs sneakyimp$ pwd
/applications/mamp/htdocs

              Also of importance is the concept of a relative path versus an absolute path. A relative path is evaluated relative to the current working directory. An absolute path is just that -- absolute. It doesn't care what the current working directory is. Absolute paths start with a slash. Relative paths do not.

              And finally there are the 'magic' directory names (. and ..). "." is the current working directory. ".." is the parent of the current working directory.

              When you type this, k-shell thinks you are trying to execute a linux command 'grr.php'. There is no such linux command:

              $ grr.php

              When you type this, you are asking the shell to execute the file grr.php in the current working directory:

              $ ./grr.php

              k-shell complains that this file is not 'executable'. you'd need to change the permissions on int (please google this, i'm getting tired of typing).

              That last one sounds like the style you should use, but apparently your PHP installation doesn't have the mysqli extensions available. You may have an older version of PHP installed.

                sneakyimp wrote:

                apparently your PHP installation doesn't have the mysqli extensions available

                It does - PHP just can't find the php.ini file that tells it to load the extension, which is why the "-c <path>" argument was suggested in a different thread.

                  So you're saying that in the folder /usr/local/opt/coolstack/php5/, there is an executable binary named 'lib'?

                  NO!
                  the reason I've been using this is that it is the ONLY path string that has resulted in being able to run the script (manually...in the shell)

                  This works perfectly in the shell:
$ php -c /usr/local/opt/coolstack/php5/lib -f __laagjob.php
...this php script runs without a hitch and does what I need it to do (run some mysql actions like replacing a table).

                  When I go digging through the directories on the server, it appears that php is actually located at: "/usr/local/opt/coolstack/php5/bin"

                  $ cd /
                  $ cd /usr/local/opt/coolstack/php5/bin
                  $ ls
                  pear peardev pecl php php-config phpize
                  $ cd php
                  ksh: php: not a directory

                  However, if I actually USE the bin direcory....
                  $ cd
                  $ php -c /usr/local/opt/coolstack/php5/bin -f grr.php
                  Fatal error: Call to undefined function mysqli_connect() in /usr/local/www/htdocs/psi/grr.php on line 2

                  but if I go back to using the lib directory in this context, then my php scripts WORK!
                  $ php -c /usr/local/opt/coolstack/php5/lib -f grr.php
                  part4: record in CRONRUNS<br>

                  I have been trying to use straight paths in the cronjob commands, but still no luck

                    OK i see.

                    Whether or not he fixes his shebang, he needs to specify the full path to his php file in his crontab. Crontabs in my opinion should never use ./file.php because you never know what the current working dir is when the crontab executes.

                    As for fixing the shebang, he can either fix that or he can type the full php command in the crontab (which i think would be preferable).

                    * * * * * php -c /usr/local/opt/coolstack/php5/lib -f /absolute/path/to/grr.php

                      Thanks a lot for your patience.

                      I have set grr.php to chmod 755.

                      I now have this crontab set:

                      • php -c /usr/local/opt/coolstack/php5/lib -f /usr/local/www/htdocs/psi/grr.php

                      I think I have actually been down this route before earlier today, but the message I'm getting back from the server is still:

                      Your "cron" job on www.blah.blah
                      php -c /usr/local/opt/coolstack/php5/lib -f /usr/local/www/htdocs/psi/grr.php
                      produced the following output:
                      sh: php: not found

                        Joseph Sliker wrote:

                        However, if I actually USE the bin direcory....
                        $ cd
                        $ php -c /usr/local/opt/coolstack/php5/bin -f grr.php
                        Fatal error: Call to undefined function mysqli_connect() in /usr/local/www/htdocs/psi/grr.php on line 2

                        but if I go back to using the lib directory in this context, then my php scripts WORK!

                        You're confusing two separate paths there, though.

                        The path to the PHP binary file is one thing, and the path that the "-c" argument expects (e.g. the directory where the php.ini file is) are two separate paths.

                        The shell expects the first parameter after the "#!" to be the path to the executable file you want to invoke. Thus, you should place the absolute path to the PHP binary file here.

                        The shell doesn't care about anything after that. Every thing else, e.g. "-c /usr/local/opt/coolstack/php5/bin -f grr.php" is just something it passes along to the executable as extra parameters.

                        Since you're not familiar with shebang lines (although I hope you're nearly there after this thread :p), you could simply ignore that method altogether as I suggested earlier and instead do something like what sneakyimp posted above. As he's mentioned a couple of times, though, the key is to use an absolute path to your PHP script so that the PHP executable can find it.

                        EDIT: Try using the full path to the "php" executable in your cronjob as well. Apparently the cronjob tasks don't have the same PATH environment variable as you do (which must include the directory where the "php" executable is located).

                          There could be another issue at work here -- that a different shell program is in effect when the crontab runs. Meaning it might be 'sh' instead of 'ksh' and different environment vars are in effect.

                          Try executing this file

                          <?php
echo $_SERVER['_'];
?>

                          I'm not sure, but I think that will echo the full absolute path to your php executable and you can replace 'php' with whatever comes out. e.g., /usr/bin/php or whatever.

                            @: I believe we already know where the 'php' binary is, according to Joseph's post above:

                            Joseph Sliker wrote:

                            $ cd /usr/local/opt/coolstack/php5/bin
                            $ ls
                            pear peardev pecl php php-config phpize

                            Still, you could always execute:

                            which php

                            or:

                            whereis php

                            to locate 'php'.

                              "which php" responds

                              /usr/local/opt/coolstack/php5/bin/php

                              sneakyimp's file responds:
                              $ php ./srvtest.php
                              /usr/local/opt/coolstack/php5/bin/php

                              The same!

                              I modifed the crontab to:
                              * php -c /usr/local/opt/coolstack/php5/bin/php -f /usr/local/www/htdocs/psi/grr.php

                              but still I get:
                              Your "cron" job on www.blah.blah
                              php -c /usr/local/opt/coolstack/php5/bin/php -f /usr/local/www/htdocs/psi/grr.php
                              produced the following output:
                              sh: php: not found

                              I think there may be a lot of fine points that I may have missed in what you both have written so far and I WILL go over them with a fine-toothed comb, but I'm starving and pooped and have to get away from this for a while. Thanks again. I'll be back, but probably not until tomorrow.

                                no we're almost there!
                                try this

                                * * * * * /usr/local/opt/coolstack/php5/bin/php
 -c /usr/local/opt/coolstack/php5/bin/php -f /usr/local/www/htdocs/psi/grr.php

                                  You changed the wrong thing.

                                  The argument following "-c" should be a path pointing to the directory where the php.ini file is (that'd be the 'lib' directory you had before).

                                  What you need to change is the path before the "-c" part. Yes, "php" is a path (a relative one). Rather than relying on the shell searching the same PATH list that you're getting in order to find "php", you should instead use an absolute path so that the shell knows exactly where the "php" binary you're referring to is located.

                                    Yes I screwed up. Why is this so hard? :rolleyes:

                                    I think this is what we want:

                                    * * * * * /usr/local/opt/coolstack/php5/bin/php -c /usr/local/opt/coolstack/php5/lib -f /usr/local/www/htdocs/psi/grr.php

                                      :eek:

                                      My reply was actually to Joseph Sliker, because I still haven't learned to check the bottom of the thread to see if there's an additional page before I reply.

                                      Incidentally and quite ironically, however, it probably sounded like I was speaking directly to you, sneakyimp. Hehe... oops! :o

                                        YEEEEEEEE HAH! Y'all did it! Thank ye, kindly pardners! **

                                        • /usr/local/opt/coolstack/php5/bin/php -c /usr/local/opt/coolstack/php5/lib -f /usr/local/www/htdocs/psi/grr.php

                                        ** I have no idea why I said it this way, being from Milwaukee and all... ain'a?

                                          Write a Reply...