php script running other php script

jlive

how I can have a php script running another php script without using the header Location ?

infact Location makes the call via http, but I want the original script be executed under crontab...

LordShryku

You can [man]include[/man] it or use an [man]exec[/man] function.

jlive

for some reason include is not proper to my case...

I was working on exec() too
but this:

<?php
   exec('/www/u/user/htdocs/test.php');
?>

is not working...

tsinka

How does the code look like that doesn't work so we can see what might be wrong with the include.

Thomas

jlive

thomas,
it's me, not the code: I don't want to use include because the scripts to be run under crontab are many and huge, so a memory and time limit exceeding may results

a former solution is working jumping from a script to the other by using the header Location, but that does not work under crontab (see http://www.phpbuilder.com/board/showthread.php?s=&threadid=10282418)

tsinka

Hi,

if you want to execute that script you might need to add a shebang line to the script, like e.g.

#!/usr/bin/php

and set the executable flag on that script.

chmod +x script.php (or chmod u+x script.php if only the owner of the script should be able to execute the script).

Thomas

LordShryku

Depending how you're accessing it. You could also just point to the executable.

exec('/usr/local/bin/php /www/u/user/htdocs/test.php');

jlive

thomas,
yes with the shebang I made a step forward (actually the test script is run with status=0)
the final result is not yet that I wanted, I'm investigating...
but I think the exec issue is resolved

what's the meaning of that #! you put before the shebang ?
where can I read something about ?

chmod
I don't think it's relevant making the script executable, since it's a php script
infact similarly I use other php scripts under crontab (with the shebang, and not running other php scripts) and those have chmod set 'not executable' and are regularly executed by crontab

LordShryku

Thr #! is the shebang. It the sybol which tells the script which binary to use when interpreting the script.

jlive

thanku LordShryku,
so why in your former post it was not ? and in my crontab (that's working) is not ?
seems optional

links to suggest about it ?

LordShryku

Well, it really is optional. You can specify the path to the binary when you execute it, or you can put the shebang in the file. Either would work. Here's a link if you want to read up. It's really a pretty standard Unix mechanism for scripting. Usually seen in shell scripting.

http://homepages.cwi.nl/~aeb/std/shebang/

jlive

great help Lord

now I'm back to my original goal: there's something not working again

now I'm using a script (test.php):

<?php
exec('#!/usr/bin/php /www/u/user/htdocs/test10.php', $output, $status);
foreach($output as $outputline) echo $outputline.'<br>';   

echo 'status='.$status.'<br>';
?>

and test10.php is:

<?php
   $s="test10";
   echo $s."<br>";
   $handle = fopen ('/www/u/user/htdocs/test10.txt', 'w'); 
   fwrite ($handle, $s."\n"); 
   fclose ($handle);    

?>

the result is:
1) status=0
2) no string 'text10' is returned in the output of test.php - the output is null
3) no file 'test10.txt' is created

the conclusion is:
test10.php is not executed, even the status returned is 0

...and I'm done again

LordShryku

Remove the shebang. Not needed since you're pointing to the binary. Just use this:

exec('/usr/bin/php /www/u/user/htdocs/test10.php', $output, $status);

Make sure /usr/bin is where the php binary is...

jlive

urright it's /usr/local/bin/php not /usr/lbin/php
now it does this:

Status: 404
Content-type: text/html
X-Powered-By: PHP/4.3.8

No input file specified.
status=255

all the lines but the last are the output of 'test10.php' flushed back to 'test.php'
and the last line 'status=255' is the result for the run of 'test.php'

now I'm going to find what those error codes mean...

tsinka

Hi,

seems like you're using the cgi version of the php executable. You might need to get the CLI version.

Read this section in the manual about command line features.

Please give me the configure options that were used to compile php (you can get it from the output of phpinfo).

Thomas

jlive

I'm still there... but now I'm convinced the error is not in the script 'executed' but still in that 'executing'

I'm using : test.php

<?php
exec('/usr/local/bin/php /www/u/user/htdocs/test10.php 2>&1', $output, $status);
foreach($output as $o) echo $o.'<br>';   

echo 'exec status='.$status.'<br>';
?>

and test10.php:

<?php
echo "Hallo!";
?>

and the result is:

Status: 404
Content-type: text/html
X-Powered-By: PHP/4.3.8

No input file specified.
exec status=255

any case, I really don't understand which input is missing and generating the 404 error

who can help ?

jlive

thomas, I see just now your message .... I'm seeing to follow your suggestion

tsinka

Hi,

.... echo "Hallo!"; ... where do you live ?

Thomas

tsinka

Hi,

another suggestion:

telnet or ssh to the server and execute the command

which php

see if it return two different directories.

About that shebang line. Do not use it in the exec command.

Either use
/usr/local/bin/php /path/script.php
in the exec command or add
#!/usr/local/bin/php
as first line on top of the script and just use /path/script.php
in exec.

But the shebang line makes only sence if this script is only used by a cron job and not through a web server.

Thomas

jlive

Thomas,
my SAPI is CGI, not CLI (I read it on phpinfo).
in the page you mentioned are interesting contributed that make me feel my probelm is well known

Adam wrote:[quote]Ok, I've had a heck of a time with PHP > 4.3.x and whether to use CLI vs CGI. The CGI version of 4.3.2 would return (in browser):

No input file specified.

And the CLI version would return:

500 Internal Server Error

It appears that in CGI mode, PHP looks at the environment variable PATH_TRANSLATED to determine the script to execute and ignores command line. That is why in the absensce of this environment variable, you get "No input file specified." However, in CLI mode the HTTP headers are not printed.[/quote]That's my error message too. I get the message because my SAPI is CGI.

He arrived to this conclusion

By modifying my CGI wrapper to create this PATH_TRANSLATED environment variable, it solved my problem, and I was able to run the CGI build of 4.3.2

How is possible to do that ?

Again, in a reply to Adam:

The basic issue was that PHP-as-CGI REALLY REALLY wants SCRIPT_FILENAME.
It ignores the command line. It ignores SCRIPT_NAME. It wants
SCRIPT_FILENAME. [...] If SCRIPT_FILENAME is not set, you'll get the dreaded "No input file specified" message. [...] You need to patch it in to make_envp.

Again, how to do this ?

The point is I have no access to the server shell and I cannot remake php.
What I can do is to move a request to the server admin, but the request should be clear (and well founded...)