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...
php script running other php script
You can [man]include[/man] it or use an [man]exec[/man] function.
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...
How does the code look like that doesn't work so we can see what might be wrong with the include.
Thomas
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)
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
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'); 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
Thr #! is the shebang. It the sybol which tells the script which binary to use when interpreting the script.
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 ?
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.
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
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...
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.8No 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...
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
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.8No 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 ?
thomas, I see just now your message .... I'm seeing to follow your suggestion
Hi,
.... echo "Hallo!"; ... where do you live ?
Thomas
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
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...)